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.

Since these parameters indeed both have the same alias, isn't that as desired? In practice, only parameters, not aliases, are offered by the GUI interface for Template Data anyway - I think aliases are just for documentation reasons mostly?

Re-opening as some of them still have the PMC and this is inconsistent, i.e. 10.1186/1471-2148-7-97

Another complaint about this here: https://www.mediawiki.org/wiki/Topic:V6u2mpy11qiu9705

In T232954#5494396, @matmarex wrote:

I remember that at some point in the migration to HHVM we discovered that HHVM's JSON parser was less strict than PHP's, and allowed the trailing commas. I don't remember if we did anything about that, but it might be the same problem?

Dupe of T190850, I think. It was declined because not every template on every wiki has a separate field for pmid, doi, pmc and need the url parameter.

Note that I also found that I can't set the values of the rest API through the page (api), but I can create the url directly.

For future reference, you can see here that the results are coming from Zotero:

In T229654#5403601, @matmarex wrote:

I asked to pull this into "Investigating" because I was very confused by the description. I think it was missing a "not", please check if that's right. Also, the issue is not reproducible at the given URL anymore, because Citoid was apparently enabled on the wiki. Is there another example?

In T228576#5354334, @Effeietsanders wrote:

In T228576#5352847, @Nikerabbit wrote:

For debugging, it would be really helpful if you could give message ids in copy-paste format.

Just to be clear: is that a request for now, or for future reports?

I think maybe for the future.

This is a big issue for wikibase integration too; at present wikidata has a constraint that the isbn be hyphenated, but in reality some records lack the hyphenation despite the constraint. Thoughts? We need to pick one and stick with it.

So the short answer is - yes, that'd be ideal. But the ISBN situation is kind of a disaster though. The hyphenation position depends on knowing the length of other elements, like registration group, and these change so they need to be *constantly updated in order to correctly hyphenate them.*