If anyone wants some context: I'm motivated by trying to migrate my existing project into Typst. I've set up syncing and replaced my bibliography.bib with the synced zotero.bib, but all my references are broken! The forums turned me onto the extra: citation key feature; I don't want to fix everything manually, I wish the seam was invisible.

By the way, Scaffold auto-formatted everything and it looks like the formatter hasn't been run on this file in ages; other than my patch here:

$ git diff --stat
 BibTeX.js | 3422 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------------------------------------------------------------
 1 file changed, 1715 insertions(+), 1707 deletions(-)

I didn't commit them because I thought that would have been toooo much. But maybe that would be something to do in a follow-up? Except it made the linter fail :/ ? I fixed the linting errors in #3538.

Except for that Scaffold was SUPER easy to use. I spent a while grepping to get oriented but once I knew to look for the word "translator" I got this done in a snap. I thought it would take me weeks of picking at it and I would never get it done, but there's a full IDE built in for working on these. I'm really impressed.

Can someone tell me why the tests say ?

Over 10 translators need to be tested, but this will take too long
and timeout the CI environment. Truncating to 10.
This is likely to happen when changing Embedded Metadata which is
loaded by pretty much every other translator or when a PR contains
a lot of changed translators.
You may want to consider adding '[ci skip]' in the commit message.
Will run tests for translators ["BibTeX","ACLWeb","AMS MathSciNet (Legacy)","AMS MathSciNet","Airiti","American > Institute of Aeronautics and Astronautics","Annual Reviews","CERN Document Server","Chicago Journal of Theoretical Computer Science","CiNii Research"]

I only touched one file.

It looks like maybe CI needs some attention? What should I do, mark this skip-ci?

• 14980c5
• 0b74b75
• Create TheCable translator #3532 (comment)
• Create Legit.ng translator #3531 (comment)
• Create Independent newspaper translator #3530 (comment)
• Create The Sun translator #3528 (comment)

I'll leave this for @AbeJellinek to decide, but I'd assume Zotero won't take this: the BibTeX translator is not intended for roundtripping and the BetterBibTeX add-on already provides this functionality (and is recommended for people who want to use Zotero while writing in LaTeX or related languages).

The CI runs on multiple translators because lots of other translators rely on the BibTeX translator -- that's also a reason why forcing original citekeys on import isn't necessarily desirable: it'd get you the citekeys used (somewhat randomly) on whatever site you're importing from. (edit: and this includes people who are not using citekeys at all and would likely be rather confused by their appearance in Extra)

Thanks for the explanation 🦢 . I wasn't sure how much attention this repo had gotten lately so I'm happy to have the feedback already 😊

So, in case case, I shouldn't have used the Import button? I followed the path of least resistance and let me be clear, it worked 99% and I'm very happy to be able to collab with my team and sort through 200 references without going mad. It's all good so far except that now I have to go and rewrite 20 pages of citations and rename my local PDF collection; and I know Zotero can manage PDFs but I want to keep copies with my projects (Zotero seems very nice and all! No shade! But it's still Someone Else's Computer and I won't trust the longevity of my projects to any such thing).

I see why scraping .bib from the web could be surprising for users, but if I'm importing my file that I've curated I want my citekeys to survive.

What if I stored to .citationkey? Keys were already in the database under .itemID, just hidden and ignored by the exporter. Switching to .citationkey exposes the original keys to the exporter, so roundtripping works, but shouldn't affect anyone who isn't using .bib syncing.

I really hope we can get this working. Zotero + Typst could be like 🤜🤛💪. They're already pretty good together, and this smooths the migration for anyone who wants write better.

The point is that you can just install the BBT add-on in Zotero and it will import with citekey because it's intended exactly for your use case (the plugin is mentioned in the thread you link to -- I don't quite understand the limitation they mention. Zotero's API BibTeX will pick up citekeys stored in Extra.
The built-in BibTeX translator has multiple use cases and having that to default to the citekey in the BibTeX could be quite confusing.

I didn't realize BBT will generate "extra: Citation Key:" entries. That's not mentioned in the thread or the BBT site. It's a twisty series of steps for something pretty basic.

I tried to run the tests locally to avoid the CI timeout; I got as far as having selenium pop open but I saw a bunch of content-security errors so I wasn't actually able to test. And I tried act just in case it was an env problem and that ran through to completion but in that case I suspect it didn't actually run the test cases. Tips welcome, I'm sort of stumped. I can run tests in Scaffold fine but I can't get the integration tests working.

Anyway, I have a good hope that this is not really disruptive and only improves things going forward. I'm looking forward to seeing Abe's take.

Another approach exposes itemID as the citekey? It already seems to be storing the original citekey there. But this would change citekeys from pre-existing databases, so maybe not.