Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BibTeX keys do not match Zotero default format #9

Closed
huldash opened this issue Aug 13, 2014 · 4 comments
Closed

BibTeX keys do not match Zotero default format #9

huldash opened this issue Aug 13, 2014 · 4 comments

Comments

@huldash
Copy link

huldash commented Aug 13, 2014

Hi,

I am using Lyz with an existing BibTeX database generated by exporting my Zotero library to BibTeX. I changed the Lyz setting for the BibTeX keys to author _ title _ year to match the Zotero default format and avoid duplicates in my bibliography. The problem is that Lyz includes the first two words in the title part of the key while Zotero only includes one word. So Zotero would write the key in your example as "tichy_foundations_1988", not "tichy_thefoundations_1988". Is there a way to make Lyz print the keys exactly like Zotero does?

Thank you,
Hulda

@wshanks
Copy link
Owner

wshanks commented Aug 13, 2014

I believe that it is not possible at the moment. It would be good to have. Let me verify what you want. Are you selecting some number of items or a collection in Zotero, right-clicking and choosing "Export selected items/collection" and then choosing the BibTeX format? And using the author_title_year format in LyZ would match the cite keys generated by Zotero if the title were a single word?

If so, then Zotero's BibTeX translator will need to compared with the createCiteKey() function in chrome/content/lyz/lyz.js for differences. I guess the simplest solution might be to make a new keyword for LyZ that just generates the Zotero cite key. A new Zotero title keyword could also be created (I don't want to change the current title keyword to maintain backwards compatibility), but the author keyword would also need to be checked for corner cases where LyZ and Zotero differ.

Looking at the LyZ function, it looks like it uses two words when the first word is short. Do the cite keys for items with long first words agree with Zotero for you?

Just checking -- I have a backlog of enhancements that I want to implement for my Zotero add-ons. How much would it help you out to have a quick fix for this issue?

@huldash
Copy link
Author

huldash commented Aug 14, 2014

You have understood the problem correctly. The cite keys do match for items with long first words in the title. However, I discovered another mismatch since yesterday. Zotero replaces missing information in the cite key with four question marks ("tichy_foundations_????") while Lyz leaves the field empty ("tichy_thefoundations_").

I am currently only using Lyz for the convenience of the "Cite in Lyx" command. I will just stop using it and cite the conventional way in Lyx until you get around to this issue. Please let me know when you do.

Thanks,
Hulda

@bewantbe
Copy link

It seems that there is a simpler solution.

Lyz plugin actually got a full (vanilla) BibTex item from Zotero BibTeX translator (id=9cb70025-a888-4a29-a210-93ec52da40d4) which should be the same as the (written) bibtex file https://github.com/willsALMANJ/lyz/blob/6330629181dfb923022eb9fd063585a7703b3674/addon/chrome/content/lyz/lyz.js#L786

Then the author year and title are parsed in https://github.com/willsALMANJ/lyz/blob/6330629181dfb923022eb9fd063585a7703b3674/addon/chrome/content/lyz/lyz.js#L902

Instead of trying to match the Zotero BibTeX translator, we can directly use the key in the original BibTex item.
https://github.com/willsALMANJ/lyz/blob/6330629181dfb923022eb9fd063585a7703b3674/addon/chrome/content/lyz/lyz.js#L908

See the pull request (#28) for details.

@wshanks
Copy link
Owner

wshanks commented Jan 4, 2019

Closing in favor of #29. Unfortunate it took four years to realize that this feature already existed.

@wshanks wshanks closed this as completed Jan 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants