[Wikidata-bugs] [Maniphest] [Commented On] T148747: Estimate hardware requirements for WDQS upgrade
Smalyshev added a comment. Note: I don't think we need 800G of diskspace there. Somewhere around 400 G would be enough for at least some time.TASK DETAILhttps://phabricator.wikimedia.org/T148747EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Deskana, SmalyshevCc: Sjoerddebruin, Gehel, Aklapper, Deskana, Smalyshev, mschwarzer, Avner, debt, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T149129: External ID formatter URLs for EC number does not get rendered as HTML link for loggend in users
Sebotic created this task.Sebotic added a project: Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONHi everyone, Recently, I noticed that, as long as I am a logged in user, a Wikidata page would not display a HTML link for the Enzyme commission number (P591). I tried that on Firefox (49.0) and Chrome (54.0) (I think this also applies to older versions) on Linux. When I log out of an account or use an anonymous session, the HTML link is being displayed as expected. I recall that I had this issues on other properties as well, but it could usually be fixed with one to several page reloads. This does not work here. Thanks and cheers, SeboticTASK DETAILhttps://phabricator.wikimedia.org/T149129EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SeboticCc: Aklapper, Sebotic, 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] T149114: Reconsider wikidata support in the REST API
bearND added a comment. +1 for dropping from me as well.TASK DETAILhttps://phabricator.wikimedia.org/T149114EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: bearNDCc: mobrovac, bearND, Mholloway, Pchelolo, Eevans, daniel, Aklapper, GWicke, D3r1ck01, Izno, Hardikj, Wikidata-bugs, aude, AuFCL, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T149114: Reconsider wikidata support in the REST API
GWicke created this task.GWicke added projects: Services (next), Wikidata, RESTBase-API, Mobile-Content-Service.Herald added a subscriber: Aklapper. TASK DESCRIPTIONBasically none of the current REST API end points in https://www.wikidata.org/api/rest_v1/ are actually useful currently. HTML contains a wrapping a large JSON blob. Nobody is using VisualEditor to edit this JSON blob. None of the derived content types like mobile sections or the page summary appear obviously useful. For the most part, wikidata information like item descriptions is consumed through individual project's REST APIs (such as the summary end point), rather than the wikidata REST API itself. We also currently process all updates for these end points the same way as for any other wiki. This means a lot of unnecessary work and storage use. So, lets revisit how we support WikiData in the REST API: If we find no actual use cases for the current WikiData REST API, then I am proposing to remove it altogether, and drop the associated storage. This saves resources, and avoids exposing an API that isn't useful or meaningfully maintained. We know that there are currently no uses for mobile sections or page summaries. Consider which use cases the REST API could actually help with for WikiData, and set up a custom project config, similar to what we already do for wiktionaries. TASK DETAILhttps://phabricator.wikimedia.org/T149114EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: GWickeCc: mobrovac, bearND, Mholloway, Pchelolo, Eevans, daniel, Aklapper, GWicke, D3r1ck01, Izno, Hardikj, Wikidata-bugs, aude, AuFCL, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Triaged] T149114: Reconsider wikidata support in the REST API
GWicke triaged this task as "Normal" priority. TASK DETAILhttps://phabricator.wikimedia.org/T149114EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: GWickeCc: mobrovac, bearND, Mholloway, Pchelolo, Eevans, daniel, Aklapper, GWicke, D3r1ck01, Izno, Hardikj, Wikidata-bugs, aude, AuFCL, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T149108: Add mw.wikibase.getEntityIdForCurrentPage for items which link to a currnt page through specific property
Jarekt added a comment. Yes that is basically T99899 except for the "identifier" part. AFAIK, identifiers, like VIAF, are a special homogeneous subset of properties. Links to pages on other wikipedia would be another, links to wikidata items would be another, sitelinks like in T74815 would be yet another. We could join this task with T99899 if the scope of T99899 was expanded, I do not know how big of a difference it makes to the solution.TASK DETAILhttps://phabricator.wikimedia.org/T149108EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: JarektCc: hoo, Jarekt, Aklapper, 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] [Updated] T149108: Add mw.wikibase.getEntityIdForCurrentPage for items which link to a currnt page through specific property
hoo added a comment. So you actually want a lookup for a the item that has P1472 with a certain value. That would be (at least very similar to) T99899, I guess.TASK DETAILhttps://phabricator.wikimedia.org/T149108EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hooCc: hoo, Jarekt, Aklapper, 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] [Claimed] T142942: [Task] Create mw.wikibase.entity:formatStatements for human readable access to statements
hoo claimed this task.hoo moved this task from Proposed to Doing on the Wikidata-Sprint-2016-10-12 board.hoo added a comment. I'm working on this, but wont manage to finish it today.TASK DETAILhttps://phabricator.wikimedia.org/T142942WORKBOARDhttps://phabricator.wikimedia.org/project/board/2253/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hooCc: thiemowmde, Aklapper, Lydia_Pintscher, daniel, aude, hoo, D3r1ck01, Izno, 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] T149108: Add mw.wikibase.getEntityIdForCurrentPage for items which link to a currnt page through specific property
Jarekt added a comment. It is not that similar to T74815. T74815 seeks to look up Q-ID of arbitrary page based on if it is used as a sitelink. This request is for Q-ID lookup of current page based on if it is used as a property. I guess we could make it so it can look up Q-ID of arbitrary page based on if it is used as a property. That would be fine with me too.TASK DETAILhttps://phabricator.wikimedia.org/T149108EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: JarektCc: hoo, Jarekt, Aklapper, 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] [Updated] T149108: Add mw.wikibase.getEntityIdForCurrentPage for items which link to a currnt page through specific property
hoo added a comment. I'm inclined to close this as invalid: This suggests to add some sugar on top of T74815 in a rather Wikimedia specific manner. If we actually want to have something like this, we probably want to change the properties use another (new) data type.TASK DETAILhttps://phabricator.wikimedia.org/T149108EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hooCc: hoo, Jarekt, Aklapper, 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] [Created] T149108: Add mw.wikibase.getEntityIdForCurrentPage for items which link to a currnt page through specific property
Jarekt created this task.Jarekt added projects: MediaWiki-extensions-WikibaseClient, Wikidata.Herald added a subscriber: Aklapper.
TASK DESCRIPTIONSitelinks from Wikidata to Commons are very unpredictable sometimes linking to categories sometimes to galleries and sometimes to other pages. On the other hand properties are very precise:
Commons category (P373) links to categories
Commons Creator page (P1472) links to creator pages
Commons gallery (P935) links to geleries
Commons Institution page (P1612) links to institution pages
image (P18) links to images
The problem is that those Commons pages are not aware that there are being linked to. I would like to have a function in LUA that when called from c:Creator:Leonardo_da_Vinci with mw.wikibase.getEntityIdForCurrentPage('P1472') would return Q762TASK DETAILhttps://phabricator.wikimedia.org/T149108EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: JarektCc: Jarekt, Aklapper, 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] [Retitled] T142942: [Task] Create mw.wikibase.entity:formatStatements for human readable access to statements
hoo changed the title from "[Task] Create mw.wikibase.entity:formatStatementValues for human readable access to statements" to "[Task] Create mw.wikibase.entity:formatStatements for human readable access to statements". TASK DETAILhttps://phabricator.wikimedia.org/T142942EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hooCc: thiemowmde, Aklapper, Lydia_Pintscher, daniel, aude, hoo, D3r1ck01, Izno, 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] T74815: [Task] Add mw.wikibase.getEntityObject by site link (title) Lua function
Jarekt added a comment. Link to the discussion on the EN-WIKI on the subject https://en.wikipedia.org/wiki/Wikipedia_talk:Wikidata/Archive_4#QID_lookup_from_enwp_article_title I came here looking for the same answer. I know the wiki and the page name and want to look up the Q-IDTASK DETAILhttps://phabricator.wikimedia.org/T74815EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: JarektCc: Jarekt, Wesalius, Zppix, czar, Strainu, Dvorapa, Base, Lucie, Pasleim, SJu, Bene, Herzi.Pinki, Mbch331, Daniel_Mietchen, Aklapper, Edgars2007, matej_suchanek, Aubrey, Accurimbono, ValterVB, Nemo_bis, Yair_rand, Liuxinyu970226, Candalua, Ricordisamoa, Wikidata-bugs, JulesWinnfield-hu, Lydia_Pintscher, hoo, D3r1ck01, Izno, aude___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T146158: Configure varnish to include wdqs nodes in codfw
Gehel closed this task as "Resolved".Gehel added a comment. This has been resolved by implementing LVS as described on T132457.TASK DETAILhttps://phabricator.wikimedia.org/T146158EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: GehelCc: Aklapper, Smalyshev, Gehel, mschwarzer, Avner, Zppix, debt, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, 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] T144380: Install and configure new WDQS nodes on codfw
Gehel closed subtask T146158: Configure varnish to include wdqs nodes in codfw as "Resolved". TASK DETAILhttps://phabricator.wikimedia.org/T144380EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: GehelCc: thcipriani, Stashbot, gerritbot, Gehel, Aklapper, Smalyshev, mschwarzer, Avner, Lewizho99, Zppix, Maathavan, debt, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, 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] [Commented On] T149005: time values should be formatted in Wikitext output (and not just use the ISO-like representation)
hoo added a comment.
In T149005#2742058, @Izno wrote:
In T149005#2742049, @hoo wrote:
E.g en.WP does not allow auto-formatted dates
In that case they are free to keep using the ISO-like representation.
By which you mean, use {{#property}} rather than {{#statement}}?
For now, yes, I guess.TASK DETAILhttps://phabricator.wikimedia.org/T149005EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hooCc: Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, gerritbot, hoo, D3r1ck01, 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] T149005: time values should be formatted in Wikitext output (and not just use the ISO-like representation)
Izno added a comment.
In T149005#2742049, @hoo wrote:
E.g en.WP does not allow auto-formatted dates
In that case they are free to keep using the ISO-like representation.
By which you mean, use {{#property}} rather than {{#statement}}?TASK DETAILhttps://phabricator.wikimedia.org/T149005EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: IznoCc: Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, gerritbot, hoo, D3r1ck01, 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] T149005: time values should be formatted in Wikitext output (and not just use the ISO-like representation)
hoo added a comment. E.g en.WP does not allow auto-formatted dates In that case they are free to keep using the ISO-like representation.TASK DETAILhttps://phabricator.wikimedia.org/T149005EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hooCc: Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, gerritbot, hoo, D3r1ck01, 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] T149005: time values should be formatted in Wikitext output (and not just use the ISO-like representation)
Izno added a comment. There are likely some "local consensus" type issues with this one. E.g en.WP does not allow auto-formatted dates (which is what I assume is meant by "formatted in Wikitext output). I do not know if other wikis have done the same.TASK DETAILhttps://phabricator.wikimedia.org/T149005EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: IznoCc: Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, gerritbot, hoo, D3r1ck01, 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] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
Izno added a comment. In T147307#2741800, @daniel wrote: In T147307#2739272, @Izno wrote: Why wouldn't you always output an HTML list at that point? Because we usually want inline rendering, not a block level element. Inline rendering is a trivial CSS fix (and can be varied based on classing on parent elements). My read of HTML5 seems to indicate it would be semantic to place it within a or a element, so I don't see an issue there. And I agree with thiemowmde at Sounds more like the disagreement is what the purpose of the new feature is, who will use it given his statement at It's a convenience feature to be used in infobox templates. Since I do not know that I would expect an infobox template to take inline content rather than block content of this sort. And I happen to agree with This output should never be parsed. in that it should not be designed to be parsed (what the clients will do, will do).TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, IznoCc: gerritbot, Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, Lewizho99, Maathavan, D3r1ck01, 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] T148988: Initial Cognate DB review
Addshore added a comment. In T148988#2742025, @jcrespo wrote: The main blocker is: is everything that this table has 100% public, or will it contain some private information. If it is fully public, it will be replicate do labs, assuming it will be useful there (I would assume yes). If there is private information, or things that could derive private information, it needs to be filtered before going to labs. Everything in this table will be public information. Labs replication would likely be useful.TASK DETAILhttps://phabricator.wikimedia.org/T148988EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AddshoreCc: hoo, Aklapper, jcrespo, Addshore, Marostegui, Minhnv-2809, D3r1ck01, Izno, Luke081515, Wikidata-bugs, aude, Darkdadaah, 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] T148988: Initial Cognate DB review
jcrespo added a comment. @Addshore I have some questions, they are not long, but they depend on each other, so I would love to chat with you when you find the time, as that will simplify the interaction. I am at Europe Timezone, so if you can find some time to meet at IRC, it would be great. The main blocker is: is everything that this table has 100% public, or will it contain some private information. If it is fully public, it will be replicate do labs, assuming it will be useful there (I would assume yes). If there is private information, or things that could derive private information, it needs to be filtered before going to labs. For the colums and indexes advice, please meet me on IRC.TASK DETAILhttps://phabricator.wikimedia.org/T148988EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: jcrespoCc: hoo, Aklapper, jcrespo, Addshore, Marostegui, Minhnv-2809, D3r1ck01, Izno, Luke081515, Wikidata-bugs, aude, Darkdadaah, 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] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
thiemowmde added a comment. Sounds more like the disagreement is what the purpose of the new feature is, who will use it, for what and how. To me your arguments sound like you are outputting XML or JSON. Sure, as a consumer of an XML stream I would not like it if some nodes are sometimes not there. But this is not relevant here. This output should never be parsed. It's a convenience feature to be used in infobox templates. Anything that "just looks wrong" from a users perspective will be rejected and not used by the communities. Any "just looking wrong" is true for commas that separate empty elements, thumbnails separated by commas, and lists that aren't lists. We did have a lengthy discussion about div vs span because of this issue. As already said above a private chat is of no value. Who is "we"? What issue? What arguments did you shared? Which arguments did you considered more relevant than others? Which arguments did you missed?TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, thiemowmdeCc: gerritbot, Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, Lewizho99, Maathavan, D3r1ck01, 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] T133028: [Story] autogenerated Wikibase documentation
thiemowmde added a comment. Did I forget to mention @hashar? Would not have been possible without him. Thank you!TASK DETAILhttps://phabricator.wikimedia.org/T133028EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, thiemowmdeCc: thiemowmde, Ladsgroup, Ricordisamoa, gerritbot, hashar, TerraCodes, Lydia_Pintscher, JanZerebecki, Tobi_WMDE_SW, Jonas, Aklapper, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331, Jay8g, Spage, greg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T66996: [Story] Automatically create Doxygen documentation of Wikibase PHP code
hashar added a comment. See https://doc.wikimedia.org/Wikibase/master/php/ for the generated output.TASK DETAILhttps://phabricator.wikimedia.org/T66996EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, hasharCc: thiemowmde, Jonas, Ladsgroup, JanZerebecki, TerraCodes, Ricordisamoa, Aklapper, Spage, hashar, Tobi_WMDE_SW, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331, Jay8g, greg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Unblock] T108946: [Epic] Improve the development infrastructure
thiemowmde closed subtask T66996: [Story] Automatically create Doxygen documentation of Wikibase PHP code as "Resolved". TASK DETAILhttps://phabricator.wikimedia.org/T108946EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmdeCc: Liuxinyu970226, Ricordisamoa, Aklapper, Lydia_Pintscher, 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] T66996: [Story] Automatically create Doxygen documentation of Wikibase PHP code
thiemowmde added subscribers: Ladsgroup, Jonas, thiemowmde.thiemowmde added a project: Wikidata-Sprint-2016-10-12.thiemowmde assigned this task to Ladsgroup.thiemowmde closed this task as "Resolved".thiemowmde moved this task from ready to go to in current sprint on the Wikidata board.thiemowmde added a comment.Herald added a project: User-Ladsgroup. See T133028#2741899 for details.TASK DETAILhttps://phabricator.wikimedia.org/T66996WORKBOARDhttps://phabricator.wikimedia.org/project/board/71/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, thiemowmdeCc: thiemowmde, Jonas, Ladsgroup, JanZerebecki, TerraCodes, Ricordisamoa, Aklapper, Spage, hashar, Tobi_WMDE_SW, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331, Jay8g, greg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T133028: [Story] autogenerated Wikibase documentation
hashar added a comment. Kudos @Ladsgroup :]TASK DETAILhttps://phabricator.wikimedia.org/T133028EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, hasharCc: thiemowmde, Ladsgroup, Ricordisamoa, gerritbot, hashar, TerraCodes, Lydia_Pintscher, JanZerebecki, Tobi_WMDE_SW, Jonas, Aklapper, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331, Jay8g, Spage, greg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T133028: [Story] autogenerated Wikibase documentation
thiemowmde added subscribers: Ladsgroup, thiemowmde.thiemowmde assigned this task to Ladsgroup.thiemowmde edited projects, added Wikidata-Sprint-2016-10-12; removed Patch-For-Review.thiemowmde closed this task as "Resolved".thiemowmde moved this task from ready to go to in current sprint on the Wikidata board.thiemowmde added a comment.Herald added a project: User-Ladsgroup. This got resolved by a series of (surprisingly) small patches: https://gerrit.wikimedia.org/r/316216 https://gerrit.wikimedia.org/r/317520 https://gerrit.wikimedia.org/r/317793 https://gerrit.wikimedia.org/r/317497 https://gerrit.wikimedia.org/r/317797 TASK DETAILhttps://phabricator.wikimedia.org/T133028WORKBOARDhttps://phabricator.wikimedia.org/project/board/71/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, thiemowmdeCc: thiemowmde, Ladsgroup, Ricordisamoa, gerritbot, hashar, TerraCodes, Lydia_Pintscher, JanZerebecki, Tobi_WMDE_SW, Jonas, Aklapper, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331, Jay8g, Spage, greg___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
daniel added a comment. In T147307#2741801, @thiemowmde wrote: I am the "poor soul" writing CSS. I can assure you, there is no problem with wrapping things that are lists in a tag that represents a list, and not doing this with things that are not a list. Well, I guess that's the crux of the disagreement, then: I think it is a list even if there is only one element, and it should be made obvious that it is a list. In particular, callers should never rely on it not being a list, even if it is commonly a single value. I don't understand why you say that. In the discussions I was involved in nobody ever said it would be a good idea to give any guarantees about inline vs. block elements. It's guaranteed to be a DOM element. That's all. We did have a lengthy discussion about div vs span because of this issue. IIRC we decided to actually guarantee an inline element there. It's rather important for the caller to know whether they will get an inline or block element.TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, danielCc: gerritbot, Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, Lewizho99, Maathavan, D3r1ck01, 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] T142940: Create client functionality for getting human readable wikitext from Wikibase statements
gerritbot added a comment. Change 317840 had a related patch set uploaded (by Thiemo Mättig (WMDE)): Enable Wikibase #statements parser function on all test wikis https://gerrit.wikimedia.org/r/317840TASK DETAILhttps://phabricator.wikimedia.org/T142940EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: gerritbotCc: gerritbot, thiemowmde, Lucie, aude, daniel, Lydia_Pintscher, Aklapper, hoo, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T149083: Security review for InterwikiSorting Extension
Addshore added a project: WMDE-QWERTY-Team-Board. TASK DETAILhttps://phabricator.wikimedia.org/T149083EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AddshoreCc: Addshore, Aklapper, Lydia_Pintscher, D3r1ck01, dpatrick, Izno, Luke081515, Wikidata-bugs, aude, JanZerebecki, Arlolra, csteipp, Mbch331, Jay8g, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T149082: Security review for Cognate Extension
Addshore added a project: WMDE-QWERTY-Team-Board. TASK DETAILhttps://phabricator.wikimedia.org/T149082EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AddshoreCc: Aklapper, Addshore, Lydia_Pintscher, D3r1ck01, dpatrick, Izno, Luke081515, Wikidata-bugs, aude, JanZerebecki, Darkdadaah, Arlolra, csteipp, Mbch331, Jay8g, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
thiemowmde added a comment. (Note: I edited my comment above.) If you were the poor soul writing a CSS rule for styling values in a statement list, you would hate any special casing here. I am the "poor soul" writing CSS. I can assure you, there is no problem with wrapping things that are lists in a tag that represents a list, and not doing this with things that are not a list. the caller would not know whether to expect a block level element, or an inline element. I don't understand why you say that. In the discussions I was involved in nobody ever said it would be a good idea to give any guarantees about inline vs. block elements. It's guaranteed to be a DOM element. That's all.TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, thiemowmdeCc: gerritbot, Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, Lewizho99, Maathavan, D3r1ck01, 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] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
daniel added a comment. In T147307#2739272, @Izno wrote: Why wouldn't you always output an HTML list at that point? Because we usually want inline rendering, not a block level element.TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, danielCc: gerritbot, Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, Lewizho99, Maathavan, D3r1ck01, 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] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
daniel added a comment. @thiemowmde wrote If the output is a single DOM element anyway, there is no need to do this. Consistency. If you were the poor soul writing a CSS rule for styling values in a statement list, you would hate any special casing here. The contrary: It will cause unnecessary confusion if a single statement is wrapped in something that claims to be a list, but is none. I think it causes confusion otherwise. This becomes very obvious the moment we support other list renderings. An with a single element is bad. Instead the element itself should be returned, not wrapped in anything. It's even worse then: If we support rendering, and we skip it for a single value, the caller would not know whether to expect a block level element, or an inline element. Your example actually makes me more convinced that we should not have a special case for single values.TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, danielCc: gerritbot, Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, Lewizho99, Maathavan, D3r1ck01, 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] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
thiemowmde added a comment. On IRC @daniel and I decided that we actually want to wrap the whole list of values in another span even if it has only one element. As argued in the comments in https://gerrit.wikimedia.org/r/317127 I disagree: The one and only guarantee we want to give is that the output is always a single DOM element (or nothing). Therefore we must wrap multiple elements in an other span. Otherwise some outputs would be "2001, 2002". This would have multiple issues that can all be avoided by wrapping it in something like …. If the output is a single DOM element anyway, there is no need to do this. The contrary: It will cause unnecessary confusion if a single statement is wrapped in something that claims to be a list, but is none. This becomes very obvious the moment we support other list renderings. An with a single element is bad. Instead the element itself should be returned, not wrapped in anything.TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, thiemowmdeCc: gerritbot, Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, Lewizho99, Maathavan, D3r1ck01, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Reassigned] T148747: Estimate hardware requirements for WDQS upgrade
Gehel reassigned this task from Gehel to Deskana.Gehel added a comment. @Deskana I reassign this to you. Let me know if you need more details or if you want me to move forward and open a hardware request for this.TASK DETAILhttps://phabricator.wikimedia.org/T148747EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Deskana, GehelCc: Gehel, Aklapper, Deskana, Smalyshev, mschwarzer, Avner, debt, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Claimed] T148747: Estimate hardware requirements for WDQS upgrade
Gehel claimed this task.Gehel added a comment. Side note: at this point, the need to increase hardware is more for availability than for scalability. Constraints: We want to be able to continue operations in the case where we loose a datacenter, including normal maintenance operations. Each data center is serving traffic in a completely isolated manner, users are sent to a specific datacenter based on network proximity. The implication here is that we don't want to rely on the secondary datacenter for the reliability of the main cluster. WDQS sometimes need full data reload, where a server being reloaded needs to be taken out of traffic for multiple days. At the moment, our clusters are composed of 2 nodes, which means that during maintenance, we are running on a single node. Goal: Increase the size of both eqiad and codfw WDQS clusters to 3 nodes (adding 1 node to each cluster) Notes: If budget is an issue, adding a node to eqiad should be the priority. That way, we can operate the eqiad cluster comfortably and in case we need to switch to codfw we accept to be in a degraded situation where major maintenance operations might be delayed. This is only a transitory solution. Once we have active/active clusters, codfw will need to be operable just as much as eqiad. This request is similar to T139482 Sizing: Hardware should be similar to the current wdqs200[12] configuration: CPU: dual Intel(R) Xeon(R) CPU E5-2620 v3 Disk: 800GB raw raided space SSD RAM: 96GB number of servers: eqiad: 1 codfw: 1 (we might be able to do without the codfw server in the short term if that is an issue)TASK DETAILhttps://phabricator.wikimedia.org/T148747EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: GehelCc: Gehel, Aklapper, Deskana, Smalyshev, mschwarzer, Avner, debt, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Manybubbles, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T147307: [RfC] Decide whether values outputted by new human readable access functionality should be wrapped in spans.
gerritbot added a comment.
Change 317127 merged by jenkins-bot:
Always wrap output of the {{#statements|…}} function in a
https://gerrit.wikimedia.org/r/317127TASK DETAILhttps://phabricator.wikimedia.org/T147307EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hoo, gerritbotCc: gerritbot, Izno, Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, hoo, Lewizho99, Maathavan, D3r1ck01, Wikidata-bugs, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T148988: Initial Cognate DB review
Addshore edited the task description. (Show Details) EDIT DETAILS... - Roughly 27 million rows in the table. In the schemas below cgti_title is the dbkey for the title as stored on the local site. cgti_key is a normalized version of this title currently based on some simply rules at https://github.com/wikimedia/mediawiki-extensions-Cognate/blob/master/src/StringNormalizer.php#L11 DELETES query on cgti_site, cgti_title, cgti_namespace SELECTS query on cgti_site, cgti_key, cgti_namespace **Current Schema**...TASK DETAILhttps://phabricator.wikimedia.org/T148988EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AddshoreCc: hoo, Aklapper, jcrespo, Addshore, Marostegui, Minhnv-2809, D3r1ck01, Izno, Luke081515, Wikidata-bugs, aude, Darkdadaah, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Edited] T148988: Initial Cognate DB review
Addshore edited the task description. (Show Details) EDIT DETAILS...The extension has been coded so that the cluster & db are configurable. For all wiktionaries a single db table would be used. The table would include a single row for each wiktionary page, initially in the main namespace. Based on https://stats.wikimedia.org/wiktionary/EN/TablesWikipediaZZ.htm Wiktionary has roughly 27 million articles which would mean the main cognate database table would initially have roughly 27 million rows. This may later be extended to other namespaces, but that would likely not increase the row count too dramatically. - One table for the Wiktionary group of wikis - Roughly 27 million rows in the table. **Current Schema**...TASK DETAILhttps://phabricator.wikimedia.org/T148988EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AddshoreCc: hoo, Aklapper, jcrespo, Addshore, Marostegui, Minhnv-2809, D3r1ck01, Izno, Luke081515, Wikidata-bugs, aude, Darkdadaah, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T148988: Initial Cognate DB review
Addshore added a project: User-Addshore. TASK DETAILhttps://phabricator.wikimedia.org/T148988EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AddshoreCc: hoo, Aklapper, jcrespo, Addshore, Marostegui, Minhnv-2809, D3r1ck01, Izno, Luke081515, Wikidata-bugs, aude, Darkdadaah, Mbch331, Jay8g, Krenair___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T149082: Security review for Cognate Extension
Addshore added a project: User-Addshore. TASK DETAILhttps://phabricator.wikimedia.org/T149082EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AddshoreCc: Aklapper, Addshore, Lydia_Pintscher, D3r1ck01, dpatrick, Izno, Luke081515, Wikidata-bugs, aude, JanZerebecki, Darkdadaah, Arlolra, csteipp, Mbch331, Jay8g, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T149083: Security review for InterwikiSorting Extension
Addshore added a project: User-Addshore. TASK DETAILhttps://phabricator.wikimedia.org/T149083EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AddshoreCc: Addshore, Aklapper, Lydia_Pintscher, D3r1ck01, dpatrick, Izno, Luke081515, Wikidata-bugs, aude, JanZerebecki, Arlolra, csteipp, Mbch331, Jay8g, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T149083: Security review for InterwikiSorting Extension
Addshore created this task.Addshore added projects: Security-Reviews, Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONProject Information Name of tool/project: InterwikiSorting (mediawiki extension) Project home page: https://www.mediawiki.org/wiki/Extension:InterwikiSorting Name of team requesting review: WMDE Primary contact: WMDE / @Addshore Target date for deployment: Unknown Link to code repository / patchset: https://gerrit.wikimedia.org/r/#/projects/mediawiki/extensions/InterwikiSorting,dashboards/default Programming Language(s) Used: PHP Description of the tool/project An extension to provide inter language link sorting on all projects. This is currently done by the Wikibase extension (and the InterwikiSorting extension has simply been factored out) Description of how the tool will be used at WMF The extension will be deployed to all sites (that Wikibase is installed on) Dependencies List dependencies, or upstream projects that this project relies on None Has this project been reviewed before? please link to tasks or wiki pages of previous reviews Only regular CR Working test environment please link or describe setup process for setting up a test environment This extension is currently working along side the Cognate extension in this Labs test environment (which you can be given access to) http://enwiktionary-cognate.wmflabs.org http://dewiktionary-cognate.wmflabs.org http://frwiktionary-cognate.wmflabs.org Simply install as a regular mediawiki extension and configure. Post-deployment name of team responsible for tool/project after deployment and primary contact WMDE / Wikidata / @Lydia_PintscherTASK DETAILhttps://phabricator.wikimedia.org/T149083EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AddshoreCc: Addshore, Aklapper, Lydia_Pintscher, D3r1ck01, dpatrick, Izno, Luke081515, Wikidata-bugs, aude, JanZerebecki, Arlolra, csteipp, Mbch331, Jay8g, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T149082: Security review for Cognate Extension
Addshore created this task.Addshore added projects: Security-Reviews, Cognate, Wikidata.Herald added a subscriber: Aklapper. TASK DESCRIPTIONProject Information Name of tool/project: Cognate (mediawiki extension) Project home page: https://www.mediawiki.org/wiki/Extension:Cognate Name of team requesting review: WMDE Primary contact: WMDE / @Addshore Target date for deployment: Unknown Link to code repository / patchset: https://gerrit.wikimedia.org/r/#/projects/mediawiki/extensions/Cognate,dashboards/default (latest patchset is https://gerrit.wikimedia.org/r/#/c/317651/ ) Programming Language(s) Used: PHP Description of the tool/project An extension to provide automatic inter language links for Wiktionary projects Description of how the tool will be used at WMF The extension will be deployed to all Wiktionary sites Dependencies List dependencies, or upstream projects that this project relies on None Has this project been reviewed before? please link to tasks or wiki pages of previous reviews Only regular CR Working test environment please link or describe setup process for setting up a test environment Labs test environment (which you can be given access to) http://enwiktionary-cognate.wmflabs.org http://dewiktionary-cognate.wmflabs.org http://frwiktionary-cognate.wmflabs.org The extension require a multi wiki setup. Post-deployment name of team responsible for tool/project after deployment and primary contact WMDE / Wikidata / @Lydia_PintscherTASK DETAILhttps://phabricator.wikimedia.org/T149082EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AddshoreCc: Aklapper, Addshore, Lydia_Pintscher, D3r1ck01, dpatrick, Izno, Luke081515, Wikidata-bugs, aude, JanZerebecki, Darkdadaah, Arlolra, csteipp, Mbch331, Jay8g, Legoktm___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T148713: Create test system on labs for the Cognate extension
Addshore added a comment. I have now also added the site http://frwiktionary-cognate.wmflabs.org/ and enabled the InterwikiSorting extension (set to sort de -> fr -> en)TASK DETAILhttps://phabricator.wikimedia.org/T148713EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AddshoreCc: Aklapper, Addshore, D3r1ck01, Izno, 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] T147062: [Task] create initial order of all properties for gadget
thiemowmde added projects: Wikidata-Sprint-2016-10-12, Wikidata-Gadgets.thiemowmde added a comment. @Glorian_Yapinus worked on an updated version of the statementSort gadget, containing all properties in an order that (mostly) makes sense, no matter at what item the user looks. The new _javascript_ source code is here: P4301.TASK DETAILhttps://phabricator.wikimedia.org/T147062EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Glorian_Yapinus, thiemowmdeCc: thiemowmde, Lea_Lacroix_WMDE, Aklapper, Charlie_WMDE, Jan_Dittrich, Lydia_Pintscher, dachary, D3r1ck01, Izno, Wikidata-bugs, aude, Ricordisamoa, Sjoerddebruin, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Unblock] T115833: [Epic] Charts as query results
Jonas closed subtask T142179: [Story] Line chart diagram as "Resolved". TASK DETAILhttps://phabricator.wikimedia.org/T115833EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: JonasCc: Yurik, StudiesWorld, Jonas, Aklapper, mschwarzer, Avner, debt, Gehel, D3r1ck01, 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
[Wikidata-bugs] [Maniphest] [Closed] T142179: [Story] Line chart diagram
Jonas closed this task as "Resolved". TASK DETAILhttps://phabricator.wikimedia.org/T142179EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: JonasCc: gerritbot, Aklapper, Jonas, mschwarzer, Avner, Lewizho99, Maathavan, debt, Gehel, D3r1ck01, 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
[Wikidata-bugs] [Maniphest] [Commented On] T149075: Check potentially flaky Wikidata browser tests: Choose multiple badges, Add reference with one snak
Tobi_WMDE_SW added a comment. "Add reference with one snak" from Oct 15th was caused by a Saucelabs hiccup, see https://wiki.saucelabs.com/display/DOCS/Common+Error+Messages#CommonErrorMessages-TheConnectionwithYourVirtualMachinewasLostandYourJobCan'tComplete I've mentioned it here as well: https://phabricator.wikimedia.org/T147401#2724873TASK DETAILhttps://phabricator.wikimedia.org/T149075EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Tobi_WMDE_SWCc: Aklapper, aude, WMDE-Fisch, Jonas, Tobi_WMDE_SW, hoo, D3r1ck01, Izno, Wikidata-bugs, zeljkofilipin, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T131661: [Story] Support for citoid in Wikidata
Mvolz added a comment. In T131661#2515755, @BrillLyle wrote: Curious if it would be possible to have whatever is currently working in Wiki Markup (the magnifier/lookup button) that does a lookup function -- and have inter-operability with Wikidata -- in addition to making Citoid work with Visual Editor? Basically could we have whatever works with Visual Editor also work with the old school Wiki Markup? I use Wiki Markup for all the templates and the granularity with citations, so I would be grateful for this, if it's possible. – Erika whatever is currently working in Wiki Markup (the magnifier/lookup button) This is refToolBar. It is hardcoded into the wikieditor, so it only works on en wiki: T94223 The editing team is working on a modern editor for wikitext that would allow citoid to work in wikitext in all languages: T130400 I'm not sure exactly what you mean by interoperability with wikidata; do you mean be able to use citations on wikidata on wikipedias? I have an old ideas lab that might interest you: https://meta.wikimedia.org/wiki/Grants:IdeaLab/Tools_for_using_wikidata_items_as_citations But essentially, in order to use wikidata directly on wikipedias, we minimally need citation templates that use wikidata, which we don't have.TASK DETAILhttps://phabricator.wikimedia.org/T131661EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: aude, MvolzCc: DarTar, Izno, Whatamidoing-WMF, czar, Daniel_Mietchen, BrillLyle, Stryn, Tobias1984, Scott_WUaS, Lydia_Pintscher, Elitre, Liuxinyu970226, Trizek-WMF, VIGNERON, Mvolz, Jdforrester-WMF, Florian, aude, Aklapper, merbst, WebIntegrity, Avner, Wess, D3r1ck01, Shangkuanlc, Jrf, OrenBochman, Husun1297, mobrovac, Wikidata-bugs, Malyacko, Etonkovidova, jayvdb, Swainr, Mbch331, Jay8g___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Commented On] T149005: time values should be formatted in Wikitext output (and not just use the ISO-like representation)
hoo added a comment. AFAIR in the past we blocked similar efforts on being able to parse all dates we output (so that they could in theory be fed back to the repo). @Lydia_Pintscher: Do we still need to block on this?TASK DETAILhttps://phabricator.wikimedia.org/T149005EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hooCc: Aklapper, Lydia_Pintscher, daniel, aude, Lucie, thiemowmde, gerritbot, hoo, D3r1ck01, Izno, Wikidata-bugs, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T148928: Wikidata integration for proveit gadget
Mvolz added a comment. You might be interested in this task, which is about adding support in citoid for wikidata: T131661 It faces a lot of the same challenges, although there it maps citoid parameters to wikidata parameters, and not template parameters directly to wikidata parameters. However, we already map citoid parameters to template parameters in several places (in VE, using template data, and also in the ref tool bar, which does it directly) so it's possible you could use a lot of the same architecture and just pass from template params, to citoid params, to wikidata params.TASK DETAILhttps://phabricator.wikimedia.org/T148928EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Sophivorus, MvolzCc: Mvolz, Daniel_Mietchen, Iniquity, Sophivorus, merbst, Wess, D3r1ck01, Shangkuanlc, Izno, Jrf, Husun1297, mobrovac, Wikidata-bugs, Etonkovidova, aude, Swainr, Jdforrester-WMF, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Created] T149075: Check potentially flaky Wikidata browser tests: Choose multiple badges, Add reference with one snak
hoo created this task.hoo added projects: Wikidata, Browser-Tests.Herald added a subscriber: Aklapper. TASK DESCRIPTIONBoth of these failed at some point on test.wikidata: https://integration.wikimedia.org/ci/job/selenium-Wikibase/BROWSER=chrome,MEDIAWIKI_ENVIRONMENT=test,PLATFORM=Linux,label=contintLabsSlave%20&&%20UbuntuTrusty/150/console respectively https://integration.wikimedia.org/ci/job/selenium-Wikibase/BROWSER=chrome,MEDIAWIKI_ENVIRONMENT=test,PLATFORM=Linux,label=contintLabsSlave%20&&%20UbuntuTrusty/142/console I would like to see whether there's anything we can/ should do here or whether we just have to take this for granted (random hiccups? :/).TASK DETAILhttps://phabricator.wikimedia.org/T149075EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hooCc: Aklapper, aude, WMDE-Fisch, Jonas, Tobi_WMDE_SW, hoo, D3r1ck01, Izno, Wikidata-bugs, zeljkofilipin, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Retitled] T148928: Wikidata integration for proveit gadget
Mvolz changed the title from "Wikidata integration" to "Wikidata integration for proveit gadget". TASK DETAILhttps://phabricator.wikimedia.org/T148928EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Sophivorus, MvolzCc: Daniel_Mietchen, Iniquity, Sophivorus, merbst, Wess, D3r1ck01, Shangkuanlc, Izno, Jrf, Husun1297, mobrovac, Wikidata-bugs, Etonkovidova, aude, Mvolz, Swainr, Jdforrester-WMF, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T148928: Wikidata integration
Mvolz added projects: Wikidata, Citoid.Herald added a project: VisualEditor. TASK DETAILhttps://phabricator.wikimedia.org/T148928EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Sophivorus, MvolzCc: Daniel_Mietchen, Iniquity, Sophivorus, merbst, Wess, D3r1ck01, Shangkuanlc, Izno, Jrf, Husun1297, mobrovac, Wikidata-bugs, Etonkovidova, aude, Mvolz, Swainr, Jdforrester-WMF, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Updated] T148928: Wikidata integration
Mvolz removed a project: VisualEditor.Herald added a project: VisualEditor. TASK DETAILhttps://phabricator.wikimedia.org/T148928EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Sophivorus, MvolzCc: Daniel_Mietchen, Iniquity, Sophivorus, merbst, Wess, D3r1ck01, Shangkuanlc, Izno, Jrf, Husun1297, mobrovac, Wikidata-bugs, Etonkovidova, aude, Mvolz, Swainr, Jdforrester-WMF, Mbch331___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
[Wikidata-bugs] [Maniphest] [Closed] T144308: [Task] Disallow Special:GoToLinkedPage in wikidata.org/robots.txt
thiemowmde closed this task as "Resolved".thiemowmde moved this task from Backlog to Done on the Wikidata-Sprint-2016-10-12 board. TASK DETAILhttps://phabricator.wikimedia.org/T144308WORKBOARDhttps://phabricator.wikimedia.org/project/board/2253/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Mbch331, thiemowmdeCc: Sjoerddebruin, TheDJ, Mbch331, Jonas, hoo, aude, Lydia_Pintscher, Tobi_WMDE_SW, Aklapper, thiemowmde, TerraCodes, D3r1ck01, MuhammadShuaib, Izno, Wikidata-bugs___ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
