[Wikidata-bugs] [Maniphest] [Commented On] T149326: Dev Summit proposal: The future of the Wikidata Query Service
srishakatux added a comment. To the owner of this session: Here is the link to the session guidelines page: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/2017/Session_Guidelines. We encourage you to recruit Note-taker(s) 2(min) and 3(max), Remote Moderator, and Advocate (optional) on the spot before the beginning of your session. Instructions about each role player's task are outlined in the guidelines. The physical version of the role cards will be made available in all the session rooms. Good luck prepping, see you at the summit! :)TASK DETAILhttps://phabricator.wikimedia.org/T149326EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Deskana, srishakatuxCc: srishakatux, cscott, Toniher, Lucie, yuvipanda, WMDE-leszek, fgiunchedi, Lydia_Pintscher, Tpt, Addshore, Qgil, Jonas, Aklapper, debt, Deskana, Smalyshev, Gehel, EBjune, Mohamedudhuman05, Xephyr826, mschwarzer, Avner, JJMC89, D3r1ck01, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Manybubbles, RobLa-WMF, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T145868: "Headless value factory should not be asked for its namespace" error on IF() + BOUND()
Smalyshev added a comment. Looks like the same issue. I'll verify them both when we get the fix.TASK DETAILhttps://phabricator.wikimedia.org/T145868EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: WikidataFacts, Smalyshev, Aklapper, Esc3300, EBjune, mschwarzer, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T154808: No longer getting Revert notifications
Dbrant created this task.Dbrant added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONOn Wikidata, I no longer seem to be able to get "revert" notifications via Echo (i.e. if I make a change to an item's description, and someone reverts it, I no longer get a notification. This is for testing of our Android app that will soon allow editing of descriptions).TASK DETAILhttps://phabricator.wikimedia.org/T154808EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: DbrantCc: Aklapper, Dbrant, D3r1ck01, Izno, 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] T151626: Investigate and decide the representation of languages and variants in Lexeme entities
Esc3300 added a comment. I expanded the description above. Here a few precisions and an explanation of a possible solution. The other day we looked into the way that the dialect of Finnish place names should be specified (discussion, WP article on some). It seems that a few may have ISO codes/IETF tags, other don't. In the current way monolingual text codes work, I think one would first have to ask the relevant administrator for these tag to define a variant tag and then wait for WMDE to add them. Alternatively, if we leave the interface open as we do for new item, one could just make up a code on the fly. The later isn't really desirable. To ensure that the variant is identified, one would need to define it through a QID of an item. This as not all variants have IETF-tags or have IETF-tags known to Wikidata. Whenever possible, output should use IETF tags. These could be defined on the item of the language. If no IETF is defined, the item of the language could also offer a fallback. (just "fi" instead of "fi- hämäläismurteet"). Once in a while, we could request new IETF tags for variants that need them. To simplify input by users (and bots/tools), it should be possible to input IETF tags (e.g. "de") instead of a QID. TASK DETAILhttps://phabricator.wikimedia.org/T151626EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Esc3300Cc: Esc3300, Darkdadaah, Nikki, Lydia_Pintscher, WMDE-leszek, thiemowmde, Denny, Micru, Aklapper, Lexicographical data, daniel, D3r1ck01, MuhammadShuaib, Izno, Psychoslave, Wikidata-bugs, aude, Gryllida, Shizhao, Arrbee, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T151626: Investigate and decide the representation of languages and variants in Lexeme entities
Esc3300 edited the task description. (Show Details) EDIT DETAILS...* an ISO code, or a IETF language tag * a Q-Item reference (possibly mapped to an ISO code or IETF tag somehow)...* dialects Of these combinations: - some have valid IETF tags - others have a valid fall-back tag - others don't have valid tags (or would have internal tags) There are several aspects that need to be considered: - (A) input of language/variant for a term - (B) definition of applicable IETF tag/update of tag for a language variant - (C) output (C) For representing lemmas (and representations and glosses) in HTML and RDF, we need IETF tags ~~ISO language codes~~. We can put ISO codes int Statements of items about languages, but then these statements must not change. We can make up ISO codes from Q-Ids, e.g. qqd-Q7832478, but that's not very useful, since consumers don't understand them. Currently, monolingual text uses: - (A) input in the form of code or selection from list of names - (B) definition in a special (internal table), mostly based on existing interface language and update through a somewhat time-consuming and opaque procedure. Only a few codes have accordingly been added. - (C) storage in the form of codes Units (for quantities) might initially have followed a model similar to monolingual text, this has then been simplified to model using QIDs. See also https://lists.wikimedia.org/pipermail/wikidata-tech/2016-November/001070.html and following.TASK DETAILhttps://phabricator.wikimedia.org/T151626EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Esc3300Cc: Darkdadaah, Nikki, Lydia_Pintscher, WMDE-leszek, thiemowmde, Denny, Micru, Aklapper, Lexicographical data, daniel, D3r1ck01, MuhammadShuaib, Izno, Psychoslave, Wikidata-bugs, aude, Gryllida, Shizhao, Arrbee, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T150060: Implement functionality for RC page 'Type of change' filters
jmatazzoni closed this task as "Resolved". TASK DETAILhttps://phabricator.wikimedia.org/T150060EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SBisson, jmatazzoniCc: Etonkovidova, gerritbot, Aklapper, Pginer-WMF, Trizek-WMF, Catrope, Quiddity, Liuxinyu970226, Mattflaschen-WMF, SBisson, jmatazzoni, Th3d3v1ls, Ramalepe, Liugev6, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331, tarlocesilion___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T150060: Implement functionality for RC page 'Type of change' filters
SBisson added a comment. In T150060#2924130, @jmatazzoni wrote: So, given the above, can we close this ticket? yesTASK DETAILhttps://phabricator.wikimedia.org/T150060EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SBissonCc: Etonkovidova, gerritbot, Aklapper, Pginer-WMF, Trizek-WMF, Catrope, Quiddity, Liuxinyu970226, Mattflaschen-WMF, SBisson, jmatazzoni, Th3d3v1ls, Ramalepe, Liugev6, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331, tarlocesilion___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Project Column] T150060: Implement functionality for RC page 'Type of change' filters
jmatazzoni moved this task from Product Review to QA Review on the Collaboration-Team-Triage (Collab-Team-Q3-Jan-Mar-2017) board.jmatazzoni added a comment. So, given the above, can we close this ticket?TASK DETAILhttps://phabricator.wikimedia.org/T150060WORKBOARDhttps://phabricator.wikimedia.org/project/board/2415/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SBisson, jmatazzoniCc: Etonkovidova, gerritbot, Aklapper, Pginer-WMF, Trizek-WMF, Catrope, Quiddity, Liuxinyu970226, Mattflaschen-WMF, SBisson, jmatazzoni, Th3d3v1ls, Ramalepe, Liugev6, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331, tarlocesilion___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T150060: Implement functionality for RC page 'Type of change' filters
jmatazzoni added a comment. The team met about this today and made the following decisions: As per T154486, all Flow edits will be captured by the Page Edits filter. We will NOT distinguish between new Flow topic creations and other flow edits, which means Flow topic creations will not be captured by the Page Creations filter. However, new Flow Topics will continue, as now, to be marked with the N by the system. @SBisson and @Mattflaschen-WMF, let me know if I've misstated or missed anything.TASK DETAILhttps://phabricator.wikimedia.org/T150060EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SBisson, jmatazzoniCc: Etonkovidova, gerritbot, Aklapper, Pginer-WMF, Trizek-WMF, Catrope, Quiddity, Liuxinyu970226, Mattflaschen-WMF, SBisson, jmatazzoni, Th3d3v1ls, Ramalepe, Liugev6, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331, tarlocesilion___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T137319: Graph Display icons should have explanatory tooltips
divadsn added a comment. I am ready, but I am missing i18n messages. Could someone please explain what these buttons actually are supposed to do? F5243240: firefox_2017-01-06_19-46-02.pngTASK DETAILhttps://phabricator.wikimedia.org/T137319EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: divadsnCc: gerritbot, divadsn, Jonas, Designbygio, Addshore, Aklapper, Yair_rand, Zppix, Th3d3v1ls, SacredWKnight, Ramalepe, Liugev6, EBjune, mschwarzer, Avner, Lewizho99, Maathavan, debt, Gehel, D3r1ck01, FloNight, Xmlizer, Izno, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, jayvdb, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T145868: "Headless value factory should not be asked for its namespace" error on IF() + BOUND()
WikidataFacts added a comment.
Another query with the same error message:
SELECT (COUNT(?x) AS ?c) WHERE {
BIND(IF(true, 1, 0) AS ?x).
}
Link
Same bug, or should I file a new ticket?TASK DETAILhttps://phabricator.wikimedia.org/T145868EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Smalyshev, WikidataFactsCc: WikidataFacts, Smalyshev, Aklapper, Esc3300, EBjune, mschwarzer, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331, Jay8g, Krenair___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T152491: Allow the EditEntity API module to work with all types of entities
daniel added a comment. In T152491#2923592, @Aleksey_WMDE wrote: If we need to wrap it in a closure I don't understand why do we need an interface in the first place? The callback is the factory for the actual deserializer object. The entity type definition file functions as a DI wiring file. It is of course possible to use the callbacks directly. And if PHP has function types, that's what I would suggest doing. But since PHP doesn't have that, it's nicer to have an interface and objects, to provide at least some type safety.TASK DETAILhttps://phabricator.wikimedia.org/T152491EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, danielCc: thiemowmde, Aleksey_WMDE, gerritbot, Jakob_WMDE, WMDE-leszek, Aklapper, Addshore, Ladsgroup, daniel, Th3d3v1ls, Ramalepe, Liugev6, Lewizho99, Maathavan, D3r1ck01, Izno, 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] T150205: Refactor SpecialNewEntity so it can be extended to SpecialNewLexeme
gerritbot added a comment. Change 330407 merged by Aleksey Bekh-Ivanov (WMDE): SpecialNewLexeme now uses HTMLItemReferenceField https://gerrit.wikimedia.org/r/330407TASK DETAILhttps://phabricator.wikimedia.org/T150205EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Aleksey_WMDE, gerritbotCc: gerritbot, WMDE-leszek, User-Daniel, Aklapper, Ladsgroup, Th3d3v1ls, Ramalepe, Liugev6, Lewizho99, Maathavan, D3r1ck01, Izno, 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] T152491: Allow the EditEntity API module to work with all types of entities
Ladsgroup added a comment. AFAIK it's the plan to wrap it up in a closure (it'll be added here)TASK DETAILhttps://phabricator.wikimedia.org/T152491EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: LadsgroupCc: thiemowmde, Aleksey_WMDE, gerritbot, Jakob_WMDE, WMDE-leszek, Aklapper, Addshore, Ladsgroup, daniel, Th3d3v1ls, Ramalepe, Liugev6, Lewizho99, Maathavan, D3r1ck01, Izno, 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] T150205: Refactor SpecialNewEntity so it can be extended to SpecialNewLexeme
gerritbot added a comment. Change 330231 merged by jenkins-bot: SpecialNewLexeme refactoring and addition of input validation https://gerrit.wikimedia.org/r/330231TASK DETAILhttps://phabricator.wikimedia.org/T150205EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Aleksey_WMDE, gerritbotCc: gerritbot, WMDE-leszek, User-Daniel, Aklapper, Ladsgroup, Th3d3v1ls, Ramalepe, Liugev6, Lewizho99, Maathavan, D3r1ck01, Izno, 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] T152491: Allow the EditEntity API module to work with all types of entities
Aleksey_WMDE added a comment. As soon as we don't need to wrap it in a closure I don't see a reason to put callback in the name - it will only bring confusion. If we need to wrap it in a closure I don't understand why do we need an interface in the first place?TASK DETAILhttps://phabricator.wikimedia.org/T152491EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, Aleksey_WMDECc: thiemowmde, Aleksey_WMDE, gerritbot, Jakob_WMDE, WMDE-leszek, Aklapper, Addshore, Ladsgroup, daniel, Th3d3v1ls, Ramalepe, Liugev6, Lewizho99, Maathavan, D3r1ck01, Izno, 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] T152491: Allow the EditEntity API module to work with all types of entities
WMDE-leszek added a comment. The more important question I think I failed to make more promiment is whether entity type definition should be providing the ChangeOpDeserializer instance or just some generic callback returning ChangeOp instance. Former seems better to me, regardless how the actual property/field in the type definition will be called. Having callback for consistency seems reasonable IMO.TASK DETAILhttps://phabricator.wikimedia.org/T152491EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, WMDE-leszekCc: thiemowmde, Aleksey_WMDE, gerritbot, Jakob_WMDE, WMDE-leszek, Aklapper, Addshore, Ladsgroup, daniel, Th3d3v1ls, Ramalepe, Liugev6, Lewizho99, Maathavan, D3r1ck01, Izno, 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] T152491: Allow the EditEntity API module to work with all types of entities
daniel added a comment. @Aleksey it seems a bit redundant here, but we use it for other callbacks in the entity type definition. I vote to keep in in the name of consistency. We could make it optional for all fields in the entity type definition. But let's have a separate discussion about that.TASK DETAILhttps://phabricator.wikimedia.org/T152491EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, danielCc: thiemowmde, Aleksey_WMDE, gerritbot, Jakob_WMDE, WMDE-leszek, Aklapper, Addshore, Ladsgroup, daniel, Th3d3v1ls, Ramalepe, Liugev6, Lewizho99, Maathavan, D3r1ck01, Izno, 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] T154474: Inject dependencies to SpecialPagesWithBadges
Addshore closed this task as "Resolved". TASK DETAILhttps://phabricator.wikimedia.org/T154474EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, AddshoreCc: gerritbot, daniel, Aklapper, Ladsgroup, Th3d3v1ls, Ramalepe, Liugev6, Lewizho99, Maathavan, D3r1ck01, Izno, 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] T152491: Allow the EditEntity API module to work with all types of entities
Aleksey_WMDE added a comment. Vote for dropping "callback" suffix.TASK DETAILhttps://phabricator.wikimedia.org/T152491EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, Aleksey_WMDECc: thiemowmde, Aleksey_WMDE, gerritbot, Jakob_WMDE, WMDE-leszek, Aklapper, Addshore, Ladsgroup, daniel, Th3d3v1ls, Ramalepe, Liugev6, Lewizho99, Maathavan, D3r1ck01, Izno, 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] T154609: Access level to Wikibase\Repo\Diff\EntityContentDiffView::getRevisionHeader() must be public
Addshore closed this task as "Resolved". TASK DETAILhttps://phabricator.wikimedia.org/T154609EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AddshoreCc: gerritbot, zhuyifei1999, ashley, Aklapper, thcipriani, Th3d3v1ls, Ramalepe, Liugev6, Lewizho99, Maathavan, D3r1ck01, Andrew-WMDE, Izno, Wikidata-bugs, aude, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T150060: Implement functionality for RC page 'Type of change' filters
SBisson added a comment. In T150060#2922068, @jmatazzoni wrote: In the scheme we've defined, Flow edits (excluding Flow edits that create a new topic) belong with Page edits and only Page edits. That should be our goal. So, to use a negative example, if I uncheck everything except Category changes, I should see Category changes only—and no Flow edits. If that is not what is happening—if Flow edits are slipping through because they're not addressed by the RC page filters—then we should fix that. @SBisson, can you clarify? Will Flow edits be included with Page edits and only Page edits? (If not, do you want to fix it in this ticket or should we create a separate ticket?) tldr: I'm working on T154486, which rolls new topics into the "new pages" filter. I will include all other Flow changes in the "page edits" filter as part of the same ticket, which I've updated accordingly. It's unfortunately not as simple as it sounds since from RC's perspective, all this data is only tagged as "Flow". There's no notion of "new" or anything else. It makes it quite hard to filter. I'll probably have to change how data is stored. The "N" is added during rendering when all the data is loaded and we can check a number of Flow-specific conditions (first version of the first reply to a non-moderated topic - it has nothing to do with the related Topic page).TASK DETAILhttps://phabricator.wikimedia.org/T150060EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SBissonCc: Etonkovidova, gerritbot, Aklapper, Pginer-WMF, Trizek-WMF, Catrope, Quiddity, Liuxinyu970226, Mattflaschen-WMF, SBisson, jmatazzoni, Th3d3v1ls, Ramalepe, Liugev6, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331, tarlocesilion___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T151626: Investigate and decide the representation of languages and variants in Lexeme entities
Micru added a comment. There is some criticism about using a fixed set of codes for the representation of languages and variants: https://en.wikipedia.org/wiki/ISO_639-3#Criticism http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.824.7083=rep1=pdf The ISO standard that was supposed to encode variants, ISO 639-6:2009, was withdrawn in 2014 with no planned replacement. However, there is the need to administer the range of options to avoid partisan edits. The current model used by the monolingual datatype works well in that case because it omits language variants. Wiktionaries sometimes mention the language variant on the pronunciation or on the definition. For instance in en-wikt tomaca only lists two pronunciations, however ca-wikt tomaca lists two pronunciations plus the dialects where the word is used (català central, and valencià). A possible solution could be to have a mandatory field for language from a fixed list administered by the community, and an optional field for variants encoded as items. Constrain checks could be performed by bots to ensure that the selected variants are in the subclass tree of a given language. Another option is to represent the language variant as a statement or qualifier. While more flexible, it adds complexity.TASK DETAILhttps://phabricator.wikimedia.org/T151626EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MicruCc: Nikki, Lydia_Pintscher, WMDE-leszek, thiemowmde, Denny, Micru, Aklapper, Lexicographical data, daniel, D3r1ck01, MuhammadShuaib, Izno, Psychoslave, Wikidata-bugs, aude, Gryllida, Shizhao, Arrbee, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T153950: Add ChangeOpDeserializer interface for services providing ChangeOps to Api\EditEntity
gerritbot added a comment. Change 330698 abandoned by Aleksey Bekh-Ivanov (WMDE): [WIP] Alternative ChangeOpDeserializer interface https://gerrit.wikimedia.org/r/330698TASK DETAILhttps://phabricator.wikimedia.org/T153950EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, gerritbotCc: gerritbot, Aklapper, Jakob_WMDE, WMDE-leszek, thiemowmde, Ladsgroup, daniel, Th3d3v1ls, Ramalepe, Liugev6, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Changed Subscribers] T152491: Allow the EditEntity API module to work with all types of entities
WMDE-leszek added subscribers: Aleksey_WMDE, thiemowmde.WMDE-leszek added a comment. @daniel @Ladsgroup @Jakob_WMDE: I've edited a task description adding an outline of how we (or at least I) imagine the mechanism would work. It has not been written down before but I believe we need this. Please go ahead and change the description if I consider something wrong, or move it some other place if there is a better one. Also pinging @Aleksey_WMDE @ and @thiemowmde as they have been involved in the discussion on ChangeOpDeserializer interfance.TASK DETAILhttps://phabricator.wikimedia.org/T152491EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, WMDE-leszekCc: thiemowmde, Aleksey_WMDE, gerritbot, Jakob_WMDE, WMDE-leszek, Aklapper, Addshore, Ladsgroup, daniel, Th3d3v1ls, Ramalepe, Liugev6, Lewizho99, Maathavan, D3r1ck01, Izno, 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] T152491: Allow the EditEntity API module to work with all types of entities
WMDE-leszek edited the task description. (Show Details) EDIT DETAILS...To allow entity types that have additional fields, we need some sort of plugin mechanism that allows EditEntity::getChangeOps to construct change-ops for the non-standard parts of the entity. Outline of how the plugin mechanism should look like as of 06.01.2017: - there should be a ChangeOpDeserializer interface introduced for services that process serialized change ops and return ChangeOp instances. Initial version of the interface has been introduced in https://gerrit.wikimedia.org/r/#/c/329376/ (already merged), with a bit different approach proposed in https://gerrit.wikimedia.org/r/#/c/330698/, - API\EditEntity should not know any details of how to generate change ops from the json-array-like input. It should be done by ChangeOpDeserializer instances. - Entity type definitions should provide a new property (work-in-progress name "changeop-deserializer-callback") that would allow EditEntity (and potentially other classes) to instantiate ChangeOp objects relevant for the particular entity type. - All item- and property-specific code currently in Api\EditEntity::getChangeOps would be moved to relevant ChangeOpDeserializers and to item and property type definitions. - entity type definitions of new entity types (MediaInfo, Lexeme) would declare instantiation of their own specific ChangeOp objects, no longer being bound to labels, descriptions etc. - Note: initially we have been considering that entity type definition would expose some callback to Api\EditEntity. That would a function getting in serialized entity change data s provided in API request, and return a ChangeOp instance. Given how ChangeOpDeserializer is modelled now maybe it would make more sense to have a property in entity type definition called "changeop-deserializer" (without a "callback" prefix) that would instantiate the actual ChangeOpDeserializer. That might be cleaner and easier to analyze?TASK DETAILhttps://phabricator.wikimedia.org/T152491EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, WMDE-leszekCc: gerritbot, Jakob_WMDE, WMDE-leszek, Aklapper, Addshore, Ladsgroup, daniel, Th3d3v1ls, Ramalepe, Liugev6, Lewizho99, Maathavan, D3r1ck01, Izno, 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] T57549: [Story] Add a new datatype for geoshapes
Micru added a subscriber: Jonas.Micru added a comment. @Jonas If your patch adds a new datatype for Commons datasets, could you please update the ticket description? It seems to me that it doesn't have anything to do with KML files...TASK DETAILhttps://phabricator.wikimedia.org/T57549EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: MicruCc: Jonas, Micru, gerritbot, mxn, Yurik, abian, Evad37, Abbe98, daniel, RolandUnger, Boshomi, Susannaanas, Christopher, Yair_rand, Kopiersperre, putnik, StudiesWorld, esbranson, DixonD, Aklapper, Sannita, Ricordisamoa, Cavila, Rits, Niharika, Kolossos, El_Grafo, Wikidata-bugs, Tobias1984, aude, Rschen7754, Liuxinyu970226, Ainali, Lydia_Pintscher, Th3d3v1ls, JakeTheDeveloper, Ramalepe, Liugev6, Lewizho99, Maathavan, D3r1ck01, Izno, TheDJ, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T154768: Allow example queries to be searched for SPARQL commands
Daniel_Mietchen created this task.Daniel_Mietchen added a project: Wikidata-Query-Service.Herald added a subscriber: Aklapper.Herald added projects: Wikidata, Discovery. TASK DESCRIPTIONRight now, the example queries can be searched by topic, which is interesting. It would be useful to also be able to search for queries on the basis of whether they use a specific SPARQL command (including things like an asterisk or subqueries and perhaps even semicolons, periods or quotation marks, as these things are hard to search for when you try to find out what they are supposed to do in SPARQL).TASK DETAILhttps://phabricator.wikimedia.org/T154768EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Daniel_MietchenCc: Daniel_Mietchen, Aklapper, EBjune, mschwarzer, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
