@Jdforrester-WMF you said elsewhere this was resolved?

This is now deployed.

In T198567#4740697, @Whatamidoing-WMF wrote:

This all looks good to me.

Is it meant to return only two results, if many are possible?

In T208500#5023704, @Mvolz wrote:

Update, checked this again and still getting a similar error (missing dependencies) with a completely fresh install of vagrant / wikidata role.

Fatal error: Uncaught Error: Class 'Wikibase\DataModel\Entity\ItemId' not found in /vagrant/mediawiki/extensions/Wikibase/lib/WikibaseLib.entitytypes.php:35 Stack trace: #0 /vagrant/mediawiki/extensions/Wikibase/client/includes/WikibaseClient.php(529): require() #1 /vagrant/mediawiki/extensions/Wikibase/client/includes/WikibaseClient.php(760): Wikibase\Client\WikibaseClient::getDefaultEntityTypes() #2 /vagrant/mediawiki/extensions/Wikibase/client/includes/WikibaseClient.php(931): Wikibase\Client\WikibaseClient::newInstance() #3 /vagrant/mediawiki/extensions/Wikibase/client/ClientHooks.php(185): Wikibase\Client\WikibaseClient::getDefaultInstance() #4 /vagrant/mediawiki/includes/Hooks.php(174): Wikibase\ClientHooks::onBeforePageDisplay(Object(OutputPage), Object(SkinVector)) #5 /vagrant/mediawiki/includes/Hooks.php(234): Hooks::callHook('BeforePageDispl...', Array, Array, NULL, '\\Wikibase\\Clien...') #6 /vagrant/mediawiki/includes/OutputPage.php(2706): Hooks::runWithoutAbort('BeforePageDispl...', Array) #7 /vagrant/mediawi in /vagrant/mediawiki/extensions/Wikibase/lib/WikibaseLib.entitytypes.php on line 35

a composer update from the mediawiki directory (as suggested above) whilst ssh-ed into the vagrant machine fixes that error.

But then I get a new one:

[59f681082f8d3edda56450ab] /wiki/Main_Page Wikimedia\Rdbms\DBQueryError from line 1522 of /vagrant/mediawiki/includes/libs/rdbms/database/Database.php: A database query error has occurred. Did you forget to run your application's database schema updater after upgrading? 
Query: SELECT ips_item_id FROM `wb_items_per_site` WHERE ips_site_id = 'enwiki' AND ips_site_page = 'Main Page' LIMIT 1 
Function: Wikimedia\Rdbms\Database::selectRow
Error: 1146 Table 'wikidatawiki.wb_items_per_site' doesn't exist (127.0.0.1)

Running

mwscript maintenance/update.php --wiki=wiki

had no effect, still get the error.

Update, checked this again and still getting a similar error (missing dependencies) with a completely fresh install of vagrant / wikidata role.

In T218238#5023150, @DLynch wrote:

Let's see... doing exactly-what-the-error-message-says and adding the npm::node_version: 10 to hieradata/common.yaml gets through with no errors after only a few runs of provision.

Does leave me with a different service-error, which is what I was originally doing this rebuilding to see if a fresh VM would fix it, but... progress. I'll go make a different task for that (T218275).

In T216248#5022684, @ppelberg wrote:

@Mvolz, the question you entered (below), does this come from a place of curiosity, from a place of wanting to verify the patch does what it's intended to do...something else entirely?

In T216248#5012931, @Esanders wrote:

Verified that we are now only seeing 'cite' in the feature column.

Thanks; I've been thinking about doing this for a while, actually. The zotero format which is the native internal format has separate fields for first name and last name, but it is indeed a bad assumption. Unfortunately since this is coming from Zotero I'm not sure we can fix it on our end in this particular case except by trying to reconstruct the split, or overwriting it maybe?

Somewhat amusingly, the anchor is kept in the DOI (when it shouldn't be) but not the url with this one: https://en.wikipedia.org/api/rest_v1/data/citation/mediawiki/https%3A%2F%2Fwww.jstor.org%2Fstable%2F10.14321%2Frhetpublaffa.21.2.0279%3Fseq%3D1%23page_scan_tab_contents

In T216456#5000567, @Joe wrote:

@Mvolz this means we can reconfigure citoid to use both proxies?

In T190841#5000864, @Aschmidt wrote:

I am sorry to say that the issue has come up again on Geman Wikipedia, so I have reopened the task for re-evaluation. @Cirdan has made a good point in describing the issue and the solution for dewiki above. In the meanwhile @Crazy1880 pointed out to an entry in OCLC that of course does contain the OCLC number, but not an ISBN. In German-speaking countries we rarely refer to OCLC ids. Also, we rarely use WorldCat, we prefer the catalogues maintained by our national libraries that issue ISBN and ISSN for German-language publications. So, I subscribe to Cirdan's description and I would be grateful if you please could change configuration accordingly.

In T134183#4999753, @matmarex wrote:

This might be the same request as T71498: VisualEditor: Please add an easy way to get from a citation template to the basic (manual) reference dialog?

They've whitelisted our IPs on request, so this is now resolved.

In T208488#4997988, @Lucas_Werkmeister_WMDE wrote:

Hm, I’m still able to edit (I tried force-reloading the page too).

It's doing it again :). Not sure if I should create a new ticket or just re-open this one, but same issue.

In T216456#4991319, @Samwalton9 wrote:

@Mvolz Do you already have a contact at JSTOR to help with this? If not we'd be happy to help!

Relevant comment from zotero: https://github.com/zotero/translators/issues/1092#issuecomment-468308989

I'm thinking this might make sense as two different tickets: for your use case @Pintoch you want the graph of the actual content language fall backs for all all the individual wikis, correct? And this would be a MediaWiki-API thing.

On thinking on this more, I think we can be quite greedy with label; we can set it at least in the guessed text language, user language, and English. This is because we're dealing with publications published in a particular language when we create items, like books and journal articles, where an untranslated label wouldn't necessarily be a bad thing and even may be the most correct thing; i.e. for edition or translations items, you actually might want the title as published, not the translated title (as opposed to book, where you might want the name of the book as it was published in each given language.)

In T217239#4989033, @Lucas_Werkmeister_WMDE wrote:

As far as I know, all those codes are MediaWiki-internal – for example, zh-classical is just some name that was picked for Classical Chinese at a time when the lzh language code had not been assigned yet. Do you think we’re likely to encounter these language codes outside of MediaWiki?

@Lucas_Werkmeister_WMDE would it make sense to expose the commented out equivalence information in https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/master/lib/includes/WikibaseContentLanguages.php#L135 ? In case we get back any language codes like those?

In T217258#4988550, @Pintoch wrote:

If you need a mapping from ISO language codes to Wikimedia ones, Wikidata-Toolkit has such a mapping: https://github.com/Wikidata/Wikidata-Toolkit/blob/3e62f93b137c25961c5a12172c7f213a720ecb67/wdtk-datamodel/src/main/java/org/wikidata/wdtk/datamodel/interfaces/WikimediaLanguageCodes.java

It might not be the most up to date mapping you can get though (I would be interested in updating it but I haven't investigated how to do that)

Default fallbacks:

@matmarex thanks for finding this, I did look before filing but this task wasn't tagged with VisualEditor-Media, is that the right tag?

In T216817#4984944, @Mvolz wrote:

In T216817#4984883, @Esanders wrote:

See also T216775 which is related to entering ISBNs.

@Mvolz Does this make sense as a proposal?

I think it makes sense. The main issue is that we actually don't have a great way to re-use citations with a page cited in ve in general.

So if we prompt someone to do this, there will be more cases where someone wants to re-use a citation, but it has a page number cited, and they may re-use the citation even though it's citing a different page number.

But I don't think it should stop us from doing it.

In T216817#4984883, @Esanders wrote:

See also T216775 which is related to entering ISBNs.

@Mvolz Does this make sense as a proposal?

So it turns out that JSTOR is just blocking us. They've done this in the past: T88323

I agree it seems a safe bet, although zotero (who we're using for all the scraping now) is a little more cautious about using metadata that appears in the head, unless there's a custom built translator for it, because you can't guarantee the metadata points to the article itself and not something else on the page, like a comment for example.

Filed: https://github.com/zotero/translation-server/issues/87

In T216456#4962958, @Aschmidt wrote:

Just to make sure: This worked before, and it only happens in JSTOR, no other resource is affected. I did not change anything about the local configuration.

In T153214#4407877, @Mvolz wrote:

In T153214#4407849, @Mvolz wrote:

In T153214#4312841, @mobrovac wrote:

In T153214#3699305, @Mvolz wrote:

Well, I agree a priori that it seems unusual. But the fix for this bug
before was a config change, and that fixed both problems :).

Which config change (or which type thereof) are you referring to?

I'm assuming https://gerrit.wikimedia.org/r/#/c/mediawiki/vagrant/+/327518/

But I made that comment ages ago so I'm not really sure.

I looks like that config change was pre-restbase so it's not really relevant anymore.

Both DOIs seem to be working in production but it appears I forgot to write a test for this, so I'll re-open until that's merged. :).

In T208305#4946185, @Mooeypoo wrote:

I don't know enough about the 'map' parameter to consider any behaviors that are needed or any edge cases to say how difficult it is to implement.

Out of a quick view, though, adding a representation to the TemplateData dialog that outputs another piece of JSON should be doable.

The documentation helped but I am still a bit vague on things, so I am not sure if I can mentor this on my own without knowing much much deeper about what "maps" parameter is supposed to do, how deep it goes, what its parts represent, etc.