@Mvolz: Yeah, I see what you mean. I wonder if it would be worth creating a Cite booksection template that remaps the parameters for Cite book.

Change 259499 merged by Mvolz:
Use basefields query parameter in citoid req

https://gerrit.wikimedia.org/r/259499

@Mvolz: In case you're interested, Citoid support in the WikiText editor is now live on English Wikipedia: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#Adding_citations_now_easier. Thanks for your help on this. Adding the base types made things a lot easier.

Is there a way to find out which wikis have citoid enabled? Or does anyone recall? @Elitre maybe?

We need to finish up updating the template data to remove the backwards compatibility.

I believe we checked whether the related json page existed (though I'm not sure I recall how) - the list we made earlier this year is at https://www.mediawiki.org/wiki/Citoid#cite_note-2 .

@Whatamidoing-WMF, did we just click through a list to find these wikis?

Thanks @Elitre, that list is a great jumping off point :).

Issue with pl unfortunately; they use all the same template for the most part, so there's no way now for it to tell it that it's a journal versus a website, since it's all publicationTitle now. Before publicationTitle = journal, now websiteTitle is being set to journal as well.

Maybe we should make the request type configurable for each wiki? Instead of hardcoded into the extension?

What are the pros and cons of each option?

@Elitre It would make the documentation more confusing; because basically it means you have different fields depending on which option that language wiki was using.

In retrospect, maybe we should have stuck to doing it the old way after all; a lot of the big wikis had already discovered workarounds for having multiple fields named different things that worked pretty well. The only one it didn't work well for was bookSection/chapter and this didn't fix that either!

So basically I would just undo everything I just did, however, on the plus side a LOT of these were missing citoid tempalte data altogether and weren't working at all, so not a total waste :)>

I'll let James, Ryan and others comment on the specific issue. (I think the priority is accommodating communities' needs if we can: if Citoid won't work for them, and they can't find a workaround, they may use it less (best case scenario), which is not our goal for sure.) Documentation problems may be not impossible to overcome, actually.

Yes, I guess what I've realised is:

*The new way makes template data *simpler* to write for most wikis. However, many of them had figured out how to actually write it well and it was working effectively.

*The old way had much superior results for pl wiki, which has been bad every since we made the changes to the service in October of last year... it has been casting ALL websites as journal articles. With this new way the only way to fix this is to make separate templates.

*If we make this configurable, it will be confusing for people to know which fields to use, whereas in the old way, the only disadvantage was it made the TD more complicated. In my estimation, having it configurable makes it more complicated than how the old way was complicated.

I think I just answered my own question...

In T114515#2461815, @Mvolz wrote:

Yes, I guess what I've realised is:

*The new way makes template data *simpler* to write for most wikis. However, many of them had figured out how to actually write it well and it was working effectively.

*The old way had much superior results for pl wiki, which has been bad every since we made the changes to the service in October of last year... it has been casting ALL websites as journal articles. With this new way the only way to fix this is to make separate templates.

*If we make this configurable, it will be confusing for people to know which fields to use, whereas in the old way, the only disadvantage was it made the TD more complicated. In my estimation, having it configurable makes it more complicated than how the old way was complicated.

I think I just answered my own question...

Yeah. :-( I think you're right that the old way (plus hand-holding on TD) is better overall for users and wikis.

Which API query VisualEditor uses isn't that important to me, but if you end up deprecating the basefields option in the API please let me know, as this is currently being used by the refToolbar in the English Wikipedia WikiText editor. I'm sure I can hack it to work around whatever is returned by the API, but it would be good to have advanced notice.

@kaldari, there's no reason to change the API, so no worries on your end!
This is just about which query the citoid visual editor extension makes.

Weirdly, nl has no oclc field in its Citeer boek template, but it does in Citeer journal.

Change 327244 had a related patch set uploaded (by Mvolz):
Use new restbase endpoint for service

https://gerrit.wikimedia.org/r/327244

Change 327244 merged by jenkins-bot:
Use new restbase endpoint for service

https://gerrit.wikimedia.org/r/327244

Extension update will roll out with wmf.8, so should be completed by 20th January if nothing goes wrong. Do the removal of the back-compat in the service in February?

Change 346749 merged by Mobrovac:
[mediawiki/services/citoid@master] Remove backwards compatibility from basefields

https://gerrit.wikimedia.org/r/346749

Mentioned in SAL (#wikimedia-operations) [2017-04-13T15:46:23Z] <mobrovac@tin> Started deploy [citoid/deploy@212800d]: Enable multiple results for T115248 and remove b/c for T114515

Mentioned in SAL (#wikimedia-operations) [2017-04-13T15:49:33Z] <mobrovac@tin> Finished deploy [citoid/deploy@212800d]: Enable multiple results for T115248 and remove b/c for T114515 (duration: 03m 10s)