In T243444#5825779, @akosiaris wrote:

it should be in the raw logs

Not sure what this refers to. If it is zotero logs, note that those don't exist. We had to turn them off as they were in a really bad format that caused issues to our logging pipeline. Assuming https://github.com/zotero/translation-server/issues/2 is addressed, we could reenable them. The disabling was done back in 827891af3d49beefc4a32042ff0ee2907dc77f0b

If it's the citoid logs, running kubectl logs -l app=citoid after having sourced .hfenv from the correct cluster directory works. But they are going to be way more difficult to parse of course.

In T243444#5825779, @akosiaris wrote:

it should be in the raw logs

Not sure what this refers to. If it is zotero logs, note that those don't exist. We had to turn them off as they were in a really bad format that caused issues to our logging pipeline. Assuming https://github.com/zotero/translation-server/issues/2 is addressed, we could reenable them. The disabling was done back in 827891af3d49beefc4a32042ff0ee2907dc77f0b

If it's the citoid logs, running kubectl logs -l app=citoid after having sourced .hfenv from the correct cluster directory works. But they are going to be way more difficult to parse of course.

But I do see in logstash a err_body_internalURI attribute in some entries that seems to indeed have what we need?

Unfortunately I'm still not seeing the ability to +2 :/

In T225415#5810312, @CCicalese_WMF wrote:

Is there a patch that you need review on? Please let us know what work you need from CPT. Untagging CPT for now.

In T208305#5808210, @srishakatux wrote:

@Mvolz Would you still be interested in mentoring the project via upcoming rounds? If so, we can promote the project via mailing lists to see if there is an interest in mentoring for the GUI part.

@akosiaris is this done then?

Just an FYI but although the VE vagrant role ideally should work, the citoid role has been broken for a while, see: T153214. If at all possible I recommend setting $wgCitoidFullRestbaseURL to https://en.wikipedia.org/api/rest_ as per https://www.mediawiki.org/wiki/Citoid#Citoid_extension in your LocalSettings.php

@Xaosflux I think this was what you were trying to report on the other task.

In T212608#5644908, @Tkarcher wrote:

Hmm, at present hairy because of other outdated packages - will create separate bugs for those.

@Pchelolo if you have no objections this seems like it could be something a student could do as part of Google-Code-in-2019?

In T210460#5685116, @Pchelolo wrote:

I've created individual tickets for the services still not addressed. Closing this umbrella ticket.

I was a little confused by the title, is the task to fix a single api page each, or for each participant to complete 10 pages? I think from the wording of the text it's a single page each, but the title makes it sounds like the student has to do all 10 pages, so I've updated the GCI page accordingly, but feel free to put it back if that's not the case :).

See: T206613 where this was originally implemented.

Imported as https://codein.withgoogle.com/dashboard/tasks/6577629709205504/

Forgive me if I'm misunderstanding, but isn't this already provided at Special:ApiSandbox, i.e. https://en.wikipedia.org/wiki/Special:ApiSandbox

In T233790#5586230, @Ladsgroup wrote:

In T233790#5586170, @Mvolz wrote:

We were already not using a global module, i.e. loading it using mw.loading elsewhere in the code, so it should not have affected the tree whatsoever.

I think there's a misunderstanding here, by global, we tend to avoid using wikibase.datamodel.* variables which happens regardless of the way you load the module (as dependency declared or lazy loaded using mw.loader)

Can you explain the problem better to me? We just squeezed all modules to one module called wikibase.datamodel and you load it whatever way you want but use it with require (more info)

In T212069#5592396, @Lucas_Werkmeister_WMDE wrote:

In T212069#4827851, @Anomie wrote:

Relevant code for this specific example: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Wikibase/+/6eea7f8d5e52a528877748391e3fae965f752018/repo/includes/Api/ResultBuilder.php#1019. Changing that "" to true should do it, although with how complicated Wikibase's code is I can't say for sure.

That would only change "missing" from "" to true, I think, whereas the example in the task description also has entities change from an object to an array. This is analogous to the change of query’s titles in MediaWiki core (which the JSON v2 documentation describes as specific to that API module).

However, that would be a massive breaking change to wbgetentities, even more so than changing claims to statements, which was previously discussed in T149410 – I can’t imagine any use of wbgetentities that would be unaffected by this. It might be something to consider for a hypothetical formatversion=3 – though even then, I’m not convinced of its usefulness, since entity IDs are much less internal than query/titles’ page IDs, and once you have multiple entities in the response an array is arguably less useful than an object – but I don’t think we should make such a change for formatversion=2.

I've put in a revert of one of these changes here: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Citoid/+/544167/

In T234420#5563537, @JTannerWMF wrote:

Hey @Mvolz let us know if you plan to pick this up or if we should move this to the freezer

I think this is just because maybe the most recent version of citoid isn't deployed on beta?

In T158465#5523650, @Astinson wrote:

@Mvolz this should be closed right?

Seems to be working okay now, I think this might have just been T223115. Closing but feel free to re-open if it doesn't seem resolved after all.

Fixed now.

Deployed, fixed for at least the two examples given.

I've added two more author slots to the TD here: https://en.wikipedia.org/w/index.php?title=Template:Cite_journal/doc&type=revision&diff=917358513&oldid=914737150&diffmode=source

Re: point 2, this is because the template data only goes up to 9 authors, unfortunately.