[Wikidata-bugs] [Maniphest] [Changed CC] T986: Use structured data on Wiktionary
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T986 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: GPHemsley, Gilles, JanZerebecki, Ricordisamoa, Liuxinyu970226, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T67626: support for complex queries
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T67626 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: Eloquence, Lydia_Pintscher, -jem-, Zellfaze, Liuxinyu970226, jkroll, Smalyshev, Wikidata-bugs, aude, GWicke, Manybubbles, daniel ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T42358: Wikidata changes in article history
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T42358 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: Tgr, Arkanosis, Lydia_Pintscher, Ainali, Stryn, matmarex, jeblad, SPQRobin, matej_suchanek, aude, Wikidata-bugs, SJu, KTC, Denny, Liuxinyu970226 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T76232: nudge when editing a statement to check reference
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T76232 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: Lydia_Pintscher, Snaterlicious, adrianheine, thiemowmde, Liuxinyu970226, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T50143: Implement complete RDF mapping for entities (tracking)
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T50143 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: adrianheine, Lydia_Pintscher, daniel, jayvdb, Wikidata-bugs, Liuxinyu970226, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T57549: Add support for geoshapes as a datatype
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T57549 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: Rschen7754, Lydia_Pintscher, Ainali, Tobias1984, aude, Wikidata-bugs, Liuxinyu970226 ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T46874: Full support for wikibase edits in enhanced changes format ("Group changes by page in recent changes and watchlist" [usenewrc])
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T46874 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: Tgr, Ltrlg, Jdforrester-WMF, He7d3r, Lydia_Pintscher, Tobi_WMDE_SW, Schnark, liangent, Abraham, Raymond, Nemo_bis, matmarex, aude, Liuxinyu970226, Wikidata-bugs ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T76231: nudge editors to add a reference when adding a new claim
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T76231 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: Lydia_Pintscher, Snaterlicious, thiemowmde, adrianheine, Liuxinyu970226, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T76233: make it possible to easily clone an existing reference from the same item
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T76233 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: Lydia_Pintscher, Snaterlicious, adrianheine, thiemowmde, Sjoerddebruin, Liuxinyu970226, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T76229: create demo infoboxes
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T76229 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: Lydia_Pintscher, hoo, Snipre, Liuxinyu970226, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T69434: make hover cards work on item links
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T69434 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: Jdforrester-WMF, Lydia_Pintscher, hoo, Prtksxna, Vibhabamba, Wikidata-bugs, Liuxinyu970226, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T68108: Store media information for files on Wikimedia Commons as structured data
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T68108 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: Tgr, JeanFred, Jdforrester-WMF, Legoktm, MarkTraceur, JohnLewis, Fabrice_Florin, Steinsplitter, Stryn, Gilles, Lydia_Pintscher, jeremyb, Bene, Lokal_Profil, jayvdb, Petrb, Dereckson, Snowolf, Ltrlg, He7d3r, Tobi_WMDE_SW, Ainali, Kelson, Nemo_bis, daniel, Multichill, Ricordisamoa, Micru, Bawolff, GPHemsley, JeroenDeDauw, Rillke, JanZerebecki, Revi, Keegan, Liuxinyu970226, Wikidata-bugs, aude, Aklapper ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T49288: track entity usage on client pages
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T49288 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: Eloquence, Legoktm, hoo, Lydia_Pintscher, Tobi_WMDE_SW, Ainali, liangent, Abraham, zhuyifei1999, daniel, Sannita, Ricordisamoa, MZMcBride, jayvdb, Micru, Daniel_Mietchen, Wikidata-bugs, greg, Liuxinyu970226, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T59589: make it possible to show the + sign in quantities on item pages
Liuxinyu970226 added a subscriber: Liuxinyu970226. TASK DETAIL https://phabricator.wikimedia.org/T59589 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Liuxinyu970226 Cc: Lydia_Pintscher, Tobi_WMDE_SW, daniel, Micru, Wikidata-bugs, Liuxinyu970226, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T86134: Autolist keeps dying
yuvipanda closed this task as "Resolved". yuvipanda claimed this task. yuvipanda added a comment. Yup, closing as fixed now. TASK DETAIL https://phabricator.wikimedia.org/T86134 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: yuvipanda Cc: Aklapper, yuvipanda, Lydia_Pintscher, Sjoerddebruin, scfc, GerardM, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T86278: Define which data the query service would store
Smalyshev added a comment. > In this case, one would not be able to distinguish this from the case where > two statements with two qualifiers each had been given originally It is possible to distinguish them since claim IDs are recorded too for bookkeeping, so the split claim would have same IDs while different claims would have different IDs. I'm still not sure why this distinction is important though. > My point was that an attacker could craft a single statement that makes you > index millions of statements. It is easy to introduce limits if this would be of any concern. Since our data does not have any large numbers, limiting expansion factor by, say, 50 or so would not impact the system and would prevent such problems. TASK DETAIL https://phabricator.wikimedia.org/T86278 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev Cc: Aklapper, Smalyshev, Lydia_Pintscher, Multichill, Magnus, daniel, JeroenDeDauw, JanZerebecki, aude, mkroetzsch, Denny, Sjoerddebruin, Tobi_WMDE_SW, jkroll, Wikidata-bugs, GWicke, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T86278: Define which data the query service would store
mkroetzsch added a comment. > This is not correct, original structure can be recovered Then I misunderstood the transformation that was proposed. My impression was that a statement with three qualifier snaks: P1 V1, P1 V2, https://phabricator.wikimedia.org/P2 V3 would be stored as two statements, one with qualifiers P1 V1, https://phabricator.wikimedia.org/P2 V3, and one with qualifiers P1 V2, https://phabricator.wikimedia.org/P2 V3. In this case, one would not be able to distinguish this from the case where two statements with two qualifiers each had been given originally. Could you explain what kind of transformation you had in mind? > Scan of the database shows there are no entries generating more than 15 > qualifier splits My point was that an attacker could craft a single statement that makes you index millions of statements. It's clear that such statements are not in the current data, since they are hopefully not needed. Again this depends on my (possibly incorrect) understanding of your intended transformation. TASK DETAIL https://phabricator.wikimedia.org/T86278 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev, mkroetzsch Cc: Aklapper, Smalyshev, Lydia_Pintscher, Multichill, Magnus, daniel, JeroenDeDauw, JanZerebecki, aude, mkroetzsch, Denny, Sjoerddebruin, Tobi_WMDE_SW, jkroll, Wikidata-bugs, GWicke, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T86278: Define which data the query service would store
Smalyshev added a comment. **This changes the structure, and the original structure is no longer represented and can no longer be faithfully recovered.** This is not correct, original structure can be recovered, though I see no reason why would you want to do so. Can you name one? **a mere 40 qualifiers (20 properties, each with two values) on one forged statement, I could create a million statements in your index -- a possible DOS attack vector** Scan of the database shows there are no entries generating more than 15 qualifier splits (at least I couldn't find any a month ago). If it ever becomes a problem, we could easily institute limits, but I think vandalism is better handled on other levels than changing our data model to avoid vandals. I see no case where 20 duplicate qualifiers would legitimately be required - duplicate qualifier is usually a wrong way to represent the claim, since it essentially claims that the same event happened in two places, two times, etc. - which usually means what should there be is two separate claims, as event happening two times is two different instances of the event. So I would claim even most existing duplicates look like data errors. TASK DETAIL https://phabricator.wikimedia.org/T86278 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev Cc: Aklapper, Smalyshev, Lydia_Pintscher, Multichill, Magnus, daniel, JeroenDeDauw, JanZerebecki, aude, mkroetzsch, Denny, Sjoerddebruin, Tobi_WMDE_SW, jkroll, Wikidata-bugs, GWicke, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T86278: Define which data the query service would store
Smalyshev added a comment. **This changes the structure, and the original structure is no longer represented and can no longer be faithfully recovered.** This is not correct, original structure can be recovered, though I see no reason why would you want to do so. Can you name one? **a mere 40 qualifiers (20 properties, each with two values) on one forged statement, I could create a million statements in your index -- a possible DOS attack vector** Scan of the database shows there are no entries generating more than 15 qualifier splits (at least I couldn't find any a month ago). If it ever becomes a problem, we could easily institute limits, but I think vandalism is better handled on other levels than changing our data model to avoid vandals. I see no case where 20 duplicate qualifiers would legitimately be required - duplicate qualifier is usually a wrong way to represent the claim, since it essentially claims that the same event happened in two places, two times, etc. - which usually means what should there be is two separate claims, as event happening two times is two different instances of the event. So I would claim even most existing duplicates look like data errors. TASK DETAIL https://phabricator.wikimedia.org/T86278 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev Cc: Aklapper, Smalyshev, Lydia_Pintscher, Multichill, Magnus, daniel, JeroenDeDauw, JanZerebecki, aude, mkroetzsch, Denny, Sjoerddebruin, Tobi_WMDE_SW, jkroll, Wikidata-bugs, GWicke, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T85347: Automatically drop redundant sitelink to redirect when merging in wbmergeitems api module
petr.matas added a comment. In https://phabricator.wikimedia.org/T85347#969150, @Addshore wrote: > I guess it would be, If there are conflicts for a site then find the actual > final target of both sitelinks (the one we are trying to add and the one > already there). > If both targets match then remove both sitelinks from both items and add the > final target (Thus also resolving redirects) This is too strong in my oppinion. Suppose that you are trying to merge the following items: - Bonnie (Q1) with sitelink [[en:Bonnie]], which is redirect to [[Bonnie and Clyde]] - Clyde (Q2) with sitelink [[en:Clyde]], which is also a redirect to [[Bonnie and Clyde]] Although the final targets are identical, neither of the redirect chains passes through the other sitelink. This indicates that Bonnie (Q1) and Clyde (Q2) may be different concepts and they should not be merged. TASK DETAIL https://phabricator.wikimedia.org/T85347 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: petr.matas Cc: Aklapper, petr.matas, hoo, daniel, Lydia_Pintscher, Addshore, Multichill, Sjoerddebruin, Legoktm, matej_suchanek, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T86278: Define which data the query service would store
mkroetzsch added a comment. @JanZerebecki I understand what you are saying about what "indexing" means here. Makes sense to me. What you are saying about my example query sounds as if you are planning to implement query execution manually. I hope this is not the case and you can just give the query to Titan to get it answered for you. You mentioned splitting certain statements with duplicate qualifiers. This changes the structure, and the original structure is no longer represented and can no longer be faithfully recovered. I don't know if this is an issue with the current data (which duplicate qualifiers are actually used?) but it is an issue in general. It also means that with a mere 40 qualifiers (20 properties, each with two values) on one forged statement, I could create a million statements in your index -- a possible DOS attack vector? An alternative technique for handling such cases is to use a special encoding for overflowing values. This is done successfully in some database implementations, but it may mean additional checks during query answering, and depending on how low in the query answering process you can do these checks, they may or may not add significant cost (hence it's a pity that Titan does not support this efficiently out of the box). TASK DETAIL https://phabricator.wikimedia.org/T86278 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev, mkroetzsch Cc: Aklapper, Smalyshev, Lydia_Pintscher, Multichill, Magnus, daniel, JeroenDeDauw, JanZerebecki, aude, mkroetzsch, Denny, Sjoerddebruin, Tobi_WMDE_SW, jkroll, Wikidata-bugs, GWicke, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T86278: Define which data the query service would store
mkroetzsch added a comment. @Smalyshev My point is merely that sitelinks and labels //can// be handled like statements. Since statements must be supported anyway, it would be sensible to reuse the data structures and query expressions defined for them. I don't think that confusion is likely, since the query language will not use the colloquial names as my examples. Properties of Wikidata will always be referred to by their Pid, whereas something like "has badge" would not have an id of this form. So it's not like having a reserved label "has badge" that competes with Wikidata property labels. Structurally, however, statements and sitelinks can all be represented in the same data structure as far as querying is concerned. Maybe you would like it better if you viewed it as a separate, independent data structure "qualified triple" that we would use to represent statements, sitelinks, and labels? There is no conceptual mix-up between the high-level terms here, just taking advantage of similar structure at a low level. If you look at common query languages like SQL, SPARQL, Cypher, etc. then you can see that they are always based on a relatively small set of structural primitives that do not have a domain-specific meaning. You can always build UIs that use domain specific terms like "sitelink" and that make them appear separate, but for implementers and API users it is very useful if some things can be unified. TASK DETAIL https://phabricator.wikimedia.org/T86278 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev, mkroetzsch Cc: Aklapper, Smalyshev, Lydia_Pintscher, Multichill, Magnus, daniel, JeroenDeDauw, JanZerebecki, aude, mkroetzsch, Denny, Sjoerddebruin, Tobi_WMDE_SW, jkroll, Wikidata-bugs, GWicke, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T86278: Define which data the query service would store
Smalyshev added a comment. @mkroetzsch the issue is that "//point in time//" is an official property in wikidata, which can be looked up and associated with property //P585//. However, "//has badge//" is not a property and as such can not be expressed in these terms. Of course, we can make a language that would have some logic - either database-backed or just whitelist-based - that would identify that "//has badge//" is a special case and create special translation for it. That would complicate the engine, but it's not the main issue. I wonder if it is really what the expectations of the users would be. After all, we display links and badges in different form than claims in the main wikidata UI - wouldn't the users of the same UI expect different handling of the sitelinks and badges in the query API too? **any query that would work over statements would also be expected to work for sitelinks** I'm not sure we want to make that claim, because I don't think it is true. The data model is different for sitelinks as opposed to claims - claims have values, qualifiers and references, while sitelinks have badges. In fact, there's very little in common between the two of them except for the fact that they are both attached to items. So I am concerned that claiming that would be rather confusing. TASK DETAIL https://phabricator.wikimedia.org/T86278 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev Cc: Aklapper, Smalyshev, Lydia_Pintscher, Multichill, Magnus, daniel, JeroenDeDauw, JanZerebecki, aude, mkroetzsch, Denny, Sjoerddebruin, Tobi_WMDE_SW, jkroll, Wikidata-bugs, GWicke, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T86278: Define which data the query service would store
mkroetzsch added a comment. @Smalyshev My suggestion was just about the surface appearance, not about the inner workings. I am saying that the following two phrases have the same structure: - "Find things with a *sitelink* that *has badge* *featured*". - "Find things with a *population* that has *point in time* *2014*". If you look at it like this, you use "badge" like a (special) qualifier property and "featured" like a value. This does not mean that the query answering will be any less efficient than with another syntax. The query engine would easily parse the queries in any case, without ambiguity, and know that sitelinks are (possibly) stored in a different way internally. Same for labels. The reason I was suggesting this unification here was that it also somehow answers the question "what do we mean by 'indexing' this data?": any query that would work over statements would also be expected to work for sitelinks, even if different structures are used internally. TASK DETAIL https://phabricator.wikimedia.org/T86278 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev, mkroetzsch Cc: Aklapper, Smalyshev, Lydia_Pintscher, Multichill, Magnus, daniel, JeroenDeDauw, JanZerebecki, aude, mkroetzsch, Denny, Sjoerddebruin, Tobi_WMDE_SW, jkroll, Wikidata-bugs, GWicke, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T86278: Define which data the query service would store
Smalyshev added a comment. @Multichill I think there is a very good reason not to index everything. The reason is that everything has costs. If we had a system with zero index cost and infinite speed, of course, no problem. But in any real system creating indexes costs, storing indexes costs and retrieving indexes costs, and these costs grow, often in non-linear fashion, the more data we put into the system. Thus, there are //very// good reasons not to index something that we do not need indexed, and not to store something we do not need stored - it would hinder the performance of the things we do need indexed and looked up quickly. @mkroetzsch Are you sure you want to unify query syntax this way? Claims are different from sitelinks - you can ask "give me sitelinks with "Featured" badge" but you can not ask "give me claims with "Featured" badge" because claims do not have badges. On the other hand, you can ask "give me claims that refer to the 20th century" but you can not ask "give me sitelinks that refer to 20th century" - because claims have qualifiers and sitelinks do not. So I am not sure it makes a lot of sense to unify them. With labels, I could represent them as claims, but that would be less efficient, and would not really improve much, since you can not really apply to labels any complex queries you can apply to claims (qualifiers, trees, references) so you do not win anything representing them as claims. Moreover, the function of labels right now is more for display (it's really hard to understand results as Q30 or Q33, "USA" and "Finland" are much better) than for anything else. @JanZerebecki what you mean by "**support traversing to the site link one is connected to and then which item that is connected to**"? If we implement sitelinks and badges, the ability of looking up for specific badge value will be present, though looking up all "Featured Article" owners may be expensive if there's a lot of them. I'm not sure I understand the traversing part. **currently if there are two qualifiers with the same property on the same statement, it will be split when importing into Titan like as if it were two statements, is this something that is acceptable or should we correct this now** Yes, this is true, but this is a technical detail of indexing. The reason for this is that indexes need simple values to index, so if we have three values for **https://phabricator.wikimedia.org/P123** in the claim, we can not put them into one variable since this could not be consumed by the index. The most simple and efficient way is to make it really three values and let the engine index each of them. There are other solutions possible but they are more cumbersome to work with, so I am inclined to stay with this one unless there's a problem identified with it that would not allow to use it. As a side note, this also allows proper grouping of paired properties like start date/end date, which are really meaningless if they are stored together as one bag and not as a set of pairs. TASK DETAIL https://phabricator.wikimedia.org/T86278 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev Cc: Aklapper, Smalyshev, Lydia_Pintscher, Multichill, Magnus, daniel, JeroenDeDauw, JanZerebecki, aude, mkroetzsch, Denny, Sjoerddebruin, Tobi_WMDE_SW, jkroll, Wikidata-bugs, GWicke, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T86488: monolingual text input missing translation of string "Language (mandatory)"
Sjoerddebruin added a project: I18n. Sjoerddebruin set Security to none. TASK DETAIL https://phabricator.wikimedia.org/T86488 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Sjoerddebruin Cc: Aklapper, Lydia_Pintscher, Lucie, Sjoerddebruin, thiemowmde, adrianheine, Wikidata-bugs, aude, Gryllida, Shizhao, Arrbee ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T86488: monolingual text input missing translation of string "Language (mandatory)"
Lydia_Pintscher created this task. Lydia_Pintscher added subscribers: Lydia_Pintscher, Lucie, Sjoerddebruin, thiemowmde, adrianheine. Lydia_Pintscher added projects: Wikidata, MediaWiki-extensions-WikibaseRepository. TASK DESCRIPTION The string "Language (mandatory)" in the input for monolingual text values apparently isn't marked for translation. We need to make it translatable. TASK DETAIL https://phabricator.wikimedia.org/T86488 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lydia_Pintscher Cc: Aklapper, Lydia_Pintscher, Lucie, Sjoerddebruin, thiemowmde, adrianheine, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T85407: improve dump documentation
aude added a subscriber: aude. aude added a comment. am i blind or confused? i don't see a link on https://www.wikidata.org/wiki/Wikidata:Main_Page first place i would look is http://dumps.wikimedia.org/. if we can add a link there (and some info), would also be great. TASK DETAIL https://phabricator.wikimedia.org/T85407 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lucie, aude Cc: Aklapper, Lydia_Pintscher, hoo, aude, Wikidata-bugs ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T85407: improve dump documentation
Lydia_Pintscher added a comment. I added a link to the data access page to the main page the other day. TASK DETAIL https://phabricator.wikimedia.org/T85407 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lucie, Lydia_Pintscher Cc: Aklapper, Lydia_Pintscher, hoo, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Reopened] T85407: improve dump documentation
hoo reopened this task as "Open". hoo added a comment. Given that people end up on IRC asking basic questions about the json dumps, I guess we need a bit more here: Link the dump documentation page more prominently (Main page? Sidebar? Footer?) and shortly explain how the dumps look like (json list, one entity per line, entities look like https://www.wikidata.org/wiki/Special:EntityData/Q183.xml). TASK DETAIL https://phabricator.wikimedia.org/T85407 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lucie, hoo Cc: Aklapper, Lydia_Pintscher, hoo, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T86278: Define which data the query service would store
JanZerebecki added a comment. I understood "indexing everything" to mean that at least support answering a query for it with an exact value and traversing to things it is connected to without iterating over anything else. (Technically for Titan a composite index over one key, see http://s3.thinkaurelius.com/docs/titan/current/indexes.html#_composite_index .) I.e. support finding badges "Featured Article" and also support traversing to the site link one is connected to and then which item that is connected to. So this does not imply any fancy indices (like over functions) nor even full text, prefix or range indices. Does it sound OK to have this as a baseline? If there are no other indices that means e.g. that we can answer "Find people whose parents are married to each other." only by looking at every human that is married (which so far is indexed by exact value for each of the lookups on its own; i.e. no combined index for married humans) and then traversing to their children where both parents are in the previous set of humans (which is AFAIK currently not helped by any index). A question about qualifiers: currently if there are two qualifiers with the same property on the same statement, it will be split when importing into Titan like as if it were two statements, is this something that is acceptable or should we correct this now? TASK DETAIL https://phabricator.wikimedia.org/T86278 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev, JanZerebecki Cc: Aklapper, Smalyshev, Lydia_Pintscher, Multichill, Magnus, daniel, JeroenDeDauw, JanZerebecki, aude, mkroetzsch, Denny, Sjoerddebruin, Tobi_WMDE_SW, jkroll, Wikidata-bugs, GWicke, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T66794: Delinker should delink and replace images on Wikidata too
Multichill added a comment. Also see https://phabricator.wikimedia.org/T86483 TASK DETAIL https://phabricator.wikimedia.org/T66794 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Multichill Cc: pywikipedia-bugs, Ladsgroup, Revi, Multichill, Steinsplitter, Lydia_Pintscher, RP88, hoo, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T86439: Create new item from client js does use no-lang tag
hoo added a comment. Mh... I thought we automatically fix that (server side) on some level... didn't we at some point? I'm not sure whether this should be solved in JavaScript. TASK DETAIL https://phabricator.wikimedia.org/T86439 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: hoo Cc: Aklapper, jeblad, hoo, thiemowmde, JanZerebecki, adrianheine, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T66794: Delinker should delink and replace images on Wikidata too
hoo added a comment. In https://phabricator.wikimedia.org/T66794#969248, @Multichill wrote: > Doing it in Wikibase itself feels wrong. It's not how it's done with normal > images and the flow of information seems to be in the wrong direction > (Commons knows about usage on Wikidata, but Wikidata doesn't know about > deletions on Commons). We've been doing that for page deletions for more than a year and it would be nice to also do that for image deletions IMO (but, as said, that would be another extension to Wikibase, not Wikibase client itself). Having such an extension to replace the existing functionality of delinker would certainly be cool, but I'm not sure someone will work on that. TASK DETAIL https://phabricator.wikimedia.org/T66794 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: hoo Cc: pywikipedia-bugs, Ladsgroup, Revi, Multichill, Steinsplitter, Lydia_Pintscher, RP88, hoo, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T86134: Autolist keeps dying
Sjoerddebruin added a comment. Autolist seems stable in the last few days, the fixes helped I think. TASK DETAIL https://phabricator.wikimedia.org/T86134 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Sjoerddebruin Cc: Aklapper, yuvipanda, Lydia_Pintscher, Sjoerddebruin, scfc, GerardM, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T66794: Delinker should delink and replace images on Wikidata too
Multichill added a comment. I'm afraid we have to rebuild delinker from the ground up based on pywikibot core instead of compat. I don't really feel like doing that, or at least not anytime soon. Getting delinker to a proper codebase should probably not be discussed in this bug, but in a new one and make this one blocking. Doing it in Wikibase itself feels wrong. It's not how it's done with normal images and the flow of information seems to be in the wrong direction (Commons knows about usage on Wikidata, but Wikidata doesn't know about deletions on Commons). TASK DETAIL https://phabricator.wikimedia.org/T66794 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Multichill Cc: pywikipedia-bugs, Ladsgroup, Revi, Multichill, Steinsplitter, Lydia_Pintscher, RP88, hoo, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Status] T66794: Delinker should delink and replace images on Wikidata too
Multichill changed the task status from "Open" to "Stalled". TASK DETAIL https://phabricator.wikimedia.org/T66794 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Multichill Cc: pywikipedia-bugs, Ladsgroup, Revi, Multichill, Steinsplitter, Lydia_Pintscher, RP88, hoo, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T86278: Define which data the query service would store
mkroetzsch added a comment. On another note, it would be good if the view on all data that is in the system is somewhat uniform. We don't want special query syntax for badges etc. This could be avoided by viewing everything as statements, possibly using some "special" properties (and qualifiers). For example, a label can be structurally represented like a statement for a property of type monolingual text. A sitelink could be represented as a statement with main property pointing to the article title and a qualifier defining the site. Doing this does not change the data, but it would unify the query syntax. Something that should *not* be represented in the query service is order. The order of statements relative to other statements (of the same property or not), the order of qualifiers, the order of reference snaks in a reference, the order of aliases -- none of this should play a role in query answering as such. Whan displaying data, it could still use the order as in Wikidata, but this is not related to indexing (e.g., it should not be possible to search for entities with third alias starting with "a" and the fifth statement from the top being about property https://phabricator.wikimedia.org/P31). TASK DETAIL https://phabricator.wikimedia.org/T86278 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev, mkroetzsch Cc: Aklapper, Smalyshev, Lydia_Pintscher, Multichill, Magnus, daniel, JeroenDeDauw, JanZerebecki, aude, mkroetzsch, Denny, Sjoerddebruin, Tobi_WMDE_SW, jkroll, Wikidata-bugs, GWicke, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T74808: Add a keyboard shortcut to "Add links"
Oxta28 added a subscriber: Oxta28. TASK DETAIL https://phabricator.wikimedia.org/T74808 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Oxta28 Cc: He7d3r, hoo, Lydia_Pintscher, Wikidata-bugs, Oxta28, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T86278: Define which data the query service would store
mkroetzsch added a comment. In https://phabricator.wikimedia.org/T86278#969184, @Multichill wrote: > I would like to turn it around. We should support indexing everything: ... > The fact that we're not creative enough to make up queries for everything > doesn't mean it isn't useful. I have to disagree with this approach of designing a (query) system. Of course supporting "everything" would be nice, but indexing always needs to be viewed in the context of a query language. Depending on the query features you support, "indexing" may mean completely different things. The requirement that "everything should be indexed" is fuzzy and vague. For example, Wikidata Query supports regular path queries (in Wikidata, Kleene-star recursion is accessed with an operator called "TREE"). When you say that references should be indexed, do you mean that it should be possible to navigate through references within regular path expressions? How about qualifiers? I think Wikidata query only supports TREE in the main statements. On the other hand, Wikidata query does not support any kind of cyclic queries ("Find people whose parents are married to each other.") even though the relevant data is indexed. The point is that you need adequate index structures for each query feature. You may have "indexed everything" and still not be able to do the queries you want. Moreover, I am creative enough to come up with queries that would be very hard to implement, yet this does not mean that we should do it. Both "everything" and "everything we are creative enough for" are poor design principles. So how to move forward? The usual approach to design a practical system is to collect use cases and requirements (example queries) and then make a clear decision what should be supported and what shouldn't. One can always revise this decision later, but it's still much better to make it explicit than to just go along and see what we get. In all of this, it must be understood that supporting "everything" is an impossible task. The question is merely where to draw the line(s). TASK DETAIL https://phabricator.wikimedia.org/T86278 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev, mkroetzsch Cc: Aklapper, Smalyshev, Lydia_Pintscher, Multichill, Magnus, daniel, JeroenDeDauw, JanZerebecki, aude, mkroetzsch, Denny, Sjoerddebruin, Tobi_WMDE_SW, jkroll, Wikidata-bugs, GWicke, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T85347: Automatically drop redundant sitelink to redirect when merging in wbmergeitems api module
Multichill added a comment. All sounds good! Should make it easier to clean up duplicates/Wikipedia article merges. TASK DETAIL https://phabricator.wikimedia.org/T85347 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Multichill Cc: Aklapper, petr.matas, hoo, daniel, Lydia_Pintscher, Addshore, Multichill, Sjoerddebruin, Legoktm, matej_suchanek, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T86278: Define which data the query service would store
Multichill added a comment. I would like to turn it around. We should support indexing everything: - Labels - Aliases - Descriptions - Sitelinks - Including badges - Statements - Including ranks etc - Including qualifiers - Including references (probably forgot something) We should have a good reason to not index something. The fact that we're not creative enough to make up queries for everything doesn't mean it isn't useful. TASK DETAIL https://phabricator.wikimedia.org/T86278 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev, Multichill Cc: Aklapper, Smalyshev, Lydia_Pintscher, Multichill, Magnus, daniel, JeroenDeDauw, JanZerebecki, aude, mkroetzsch, Denny, Sjoerddebruin, Tobi_WMDE_SW, jkroll, Wikidata-bugs, GWicke, Manybubbles ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T86191: Give user indication how to influence preferred language selection
Nemo_bis edited the task description. Nemo_bis set Security to none. TASK DETAIL https://phabricator.wikimedia.org/T86191 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nemo_bis Cc: Aklapper, Lydia_Pintscher, siebrand, Amire80, deryckchan, Snaterlicious, adrianheine, thiemowmde, Tobi_WMDE_SW, Nemo_bis, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T62369: Make "in other language box" configurable
Nemo_bis edited the task description. TASK DETAIL https://phabricator.wikimedia.org/T62369 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nemo_bis Cc: Lydia_Pintscher, siebrand, Amire80, deryckchan, Snaterlicious, adrianheine, thiemowmde, Nemo_bis, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T85347: Automatically drop redundant sitelink to redirect when merging in wbmergeitems api module
Addshore added a comment. So the bit of code we would need to touch is this method > https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/master/repo/includes/ChangeOp/ChangeOpsMerge.php#L199 I guess it would be, If there are conflicts for a site then find the actual final target of both sitelinks (the one we are trying to add and the one already there). If both targets match then remove both sitelinks from both items and add the final target (Thus also resolving redirects) TASK DETAIL https://phabricator.wikimedia.org/T85347 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Addshore Cc: Aklapper, petr.matas, hoo, daniel, Lydia_Pintscher, Addshore, Multichill, Sjoerddebruin, Legoktm, matej_suchanek, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T62369: Make "in other language box" configurable
Lydia_Pintscher added a comment. It is about the repository. TASK DETAIL https://phabricator.wikimedia.org/T62369 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lydia_Pintscher Cc: Lydia_Pintscher, siebrand, Amire80, deryckchan, Snaterlicious, adrianheine, thiemowmde, Nemo_bis, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T62369: Make "in other language box" configurable
Amire80 added a comment. Just to make sure again: Is this about the item pages in Wikibase repo, about the interlanguage links list in Wikibase clients or about both? In the English Wikipedia the interlanguage links list's title is locally customized to "Languages", but the message in core MediaWiki is "In other languages". TASK DETAIL https://phabricator.wikimedia.org/T62369 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Amire80 Cc: Lydia_Pintscher, siebrand, Amire80, deryckchan, Snaterlicious, adrianheine, thiemowmde, Nemo_bis, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Triaged] T86439: Create new item from client js does use no-lang tag
Lydia_Pintscher triaged this task as "Normal" priority. Lydia_Pintscher added subscribers: hoo, thiemowmde, JanZerebecki, adrianheine. Lydia_Pintscher edited projects, added MediaWiki-extensions-WikibaseRepository; removed MediaWiki-extensions-WikibaseClient. Lydia_Pintscher set Security to none. TASK DETAIL https://phabricator.wikimedia.org/T86439 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lydia_Pintscher Cc: Aklapper, jeblad, hoo, thiemowmde, JanZerebecki, adrianheine, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T86331: Implement sitelinks and badges
Lydia_Pintscher added a project: Wikidata. TASK DETAIL https://phabricator.wikimedia.org/T86331 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev, Lydia_Pintscher Cc: Aklapper, Smalyshev, jkroll, Wikidata-bugs, aude, GWicke, Manybubbles, daniel ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T86330: Implement import of references
Lydia_Pintscher added a project: Wikidata. TASK DETAIL https://phabricator.wikimedia.org/T86330 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev, Lydia_Pintscher Cc: Aklapper, Smalyshev, jkroll, Wikidata-bugs, aude, GWicke, Manybubbles, daniel ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T86439: Create new item from client js does use no-lang tag
Lydia_Pintscher added a project: Wikidata. TASK DETAIL https://phabricator.wikimedia.org/T86439 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lydia_Pintscher Cc: Aklapper, jeblad, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T86217: Create unit tests for data import process
Lydia_Pintscher added a project: Wikidata. TASK DETAIL https://phabricator.wikimedia.org/T86217 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Smalyshev, Lydia_Pintscher Cc: Aklapper, Smalyshev, jkroll, Wikidata-bugs, aude, GWicke, Manybubbles, daniel ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Project Column] T86453: Cannot add url values as an anonymous or unconfirmed user
Lydia_Pintscher moved this task to consider for next sprint on the Wikidata workboard. TASK DETAIL https://phabricator.wikimedia.org/T86453 WORKBOARD https://phabricator.wikimedia.org/project/board/71/ REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lydia_Pintscher Cc: Aklapper, aude, tstarling, Wikidata-bugs ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Triaged] T86453: Cannot add url values as an anonymous or unconfirmed user
Lydia_Pintscher triaged this task as "High" priority. Lydia_Pintscher added a subscriber: tstarling. TASK DETAIL https://phabricator.wikimedia.org/T86453 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lydia_Pintscher Cc: Aklapper, aude, tstarling, Wikidata-bugs ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T62369: Make "in other language box" configurable
Lydia_Pintscher added a comment. No this is about actually providing a way to influence the in-other-languages box right in place. TASK DETAIL https://phabricator.wikimedia.org/T62369 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lydia_Pintscher Cc: Lydia_Pintscher, siebrand, Amire80, deryckchan, Snaterlicious, adrianheine, thiemowmde, Nemo_bis, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T62369: Make "in other language box" configurable
Nemo_bis added a subscriber: Nemo_bis. Nemo_bis added a comment. This is about the repo only, right? That is, https://phabricator.wikimedia.org/T41190 TASK DETAIL https://phabricator.wikimedia.org/T62369 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nemo_bis Cc: Lydia_Pintscher, siebrand, Amire80, deryckchan, Snaterlicious, adrianheine, thiemowmde, Nemo_bis, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed CC] T86191: Give user indication how to influence preferred language selection
Nemo_bis added a subscriber: Nemo_bis. Nemo_bis added a comment. Is this about the languages shown on Wikidata items for labels and descriptions, AKA https://phabricator.wikimedia.org/T56734? TASK DETAIL https://phabricator.wikimedia.org/T86191 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nemo_bis Cc: Aklapper, Lydia_Pintscher, siebrand, Amire80, deryckchan, Snaterlicious, adrianheine, thiemowmde, Tobi_WMDE_SW, Nemo_bis, Wikidata-bugs, aude ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T56734: Default lang when adding items
Nemo_bis edited the task description. Nemo_bis set Security to none. TASK DETAIL https://phabricator.wikimedia.org/T56734 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nemo_bis Cc: wikidata-bugs, Snaterlicious, Addshore, Lydia_Pintscher, Wikidata-bugs, KTC ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T56734: Default lang when adding items
Nemo_bis edited the task description. Nemo_bis set Security to none. TASK DETAIL https://phabricator.wikimedia.org/T56734 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign . EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Nemo_bis Cc: wikidata-bugs, Snaterlicious, Addshore, Lydia_Pintscher, Wikidata-bugs, KTC ___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs