CSL-JSON vs. bib for references

[sbfnk]

Is anyone else finding working with CSL-JSON a pain or am I the only one? All my tooling is set up for bibtex so I end up inefficiently converting reference files back and forth a lot (or avoiding references altogether). And most journals don’t offer CSL-JSON export whereas they pretty much all offer bib export. Is there no other way to get around the language identification issue, or am I the only one who struggles with this?

[jamesmbaazam]

Ensuing discussion on Slack:

@pratikunterwegs Perhaps an automated workflow that converts Bibtex to CSL-JSON using pandoc? Could even be a pre-commit hook

@sbfnk
I’d still have to convert CSL-JSON to bibtex first every time when working with a repo.

@pratikunterwegs I see - is there an example I could look at to check for possible solutions? I think our approach is to manage the references using Zotero

@sbfnk currently trying to write a vignette for bpmodels adding to references here

@sbfnk I think our approach is to manage the references using Zotero
So I assume with Zotero you could load that file, add a reference, save and you’d be done? That seems fine but we probably don’t want to lock ourselves into one referencing tool (I realise they may be others that work natively with CSL-YAML but none that I’ve worked with do).

@pratikunterwegs Well, I maintain a ‘collection’ on Zotero to which I add references, and export the ones we need (ideally from a sub-collection) to the references.json file

@pratikunterwegs There is an ROpenSci page on reference manager R packages, still looking to see whether something might work in this case, mostly relates to reading and exporting CSL-JSON
ropensci.orgropensci.org
A Roundup of R Tools for Handling BibTeX
Some tips around the use of citations/references in R Markdown, in particular with RefManageR

@pratikunterwegs
Appears not - the CSL-JSON format seems to be the stumbling block. Might be a good idea for a helper package for us to write, or a PR to make to {RefManageR}!

@jamesmbaazam Another solution would be to add the bibtex file in a subfolder in /vignettes and tell linguist to ignore that path. So we could just add the .bib file to vignettes/references and add vignettes/references/* linguist-documentation
to .gitattributes.

@TimTaylor Can you just include .bib files generally (irrespective of location) within linguist-documentation?

@TimTaylor FWIW - I definitely prefer this approach of ignoring .bib files as opposed to forcing the use of csl-json which does seem to add friction

@pratikunterwegs
Reading through this thread [referring to a Slack thread], this sounds like a solution we’d discussed and also don’t seem to have strong preferences on, so probably easiest to have linguist ignore .bib files.

@jamesmbaazam I think I did have a strong preference for ignoring .bibtex files as it won't be immediately clear to a future maintainer the reason why we use yaml instead of .bib. (edited for GitHub)

@TimTaylor Out of curiosity - what's the actual problem if linguist misidentifies the "main" language. Would using the r and rstats topics be better in this case anyway. The default's for linguist seem fine and the way they currently handle stat exclusions seems appropriate. Basically my question is - "why worry about this at all?"

@jamesmbaazam

Basically my question is - "why worry about this at all?"

It started with me being annoyed by {bpmodels} being categorised as being majorly written in .tex 😅 (edited)

@TimTaylor Yeah so that's why I think it's not an issue. If anything, to me it's a GitHub UX issue. It reduces the repository overview to one language as opposed to the within repository percentage breakdown. If you moved to a more barebones git hosting service it wouldn't be there anyway.

Repos can still be tagged with topics which are more relevant for discoverability (I'd have thought??)

[Bisaloo]

It does impact discoverability as a repo associated with the wrong language cannot be found via GitHub search with language:R.

So I do believe we should care. But I don't have a strong opinion on CSL vs linguist ignoring bibtex files (as long as we are specific in our filters to only impact bibtex files).

[TimTaylor]

It does impact discoverability as a repo associated with the wrong language cannot be found via GitHub search with language:R.

Does that not feel like a GitHub bug though? They have the breakdown for the languages used so if, for example, I had a 51:49 C v R split I'd still want that to discover R

[Bisaloo]

I probably wouldn't call it a bug as I believe it's an explicit design choice.

I couldn't find a related issue in https://github.com/orgs/community/discussions?discussions_q=is%3Aopen+label%3A%22Code+Search+and+Navigation%22 so we could always try to report it but I haven't had much success with bug reports / feature requests to GitHub