Editor wildcards do not output anything

[living-creatures]

The wildcards for editors (%d, %D, %L, %l) currently do not output anything when used in Renaming Rules.

ZotFile v5.0.16 Zotero v5.0.97-beta.50+5f61ac23a

[daaaaaaaaaniel]

This is still the case. It's been discussed in the Zotero forums as well.
Not only do the editor wildcards not work as described in the documentation. The wildcard %a which is stated to not include editors does in actuality use editors or authors.

[ZBiener]

Editor wildcards still show as "undefined" as of 5.1.2.

[ZBiener]

OK. I figured out the necessary changes to Zotfile. However, before I submit a pull request (my first ever!), two questions about functionality to those this functionality matters to:

1. This concerns the edit to the documentation submitted above. Instead of fixing the documentation, we can now fix Zotfile itself to match the unmodified documentation. That is, %a can return only authors. However, It is clear that the intention of whoever programmed the wildcard function was that %a would return both Authors and Editors (it isn’t just a bug).

   Which is the actually desired behavior?

   I believe that the unmodified documentation makes more sense (i.e., %a should only be authors). Any reason to prefer the existing behavior?

2. Zotero allows for several types of authors: author, bookAuthor, and reviewedAuthor. Similarly, it has two editorial types: editor, seriesEditor. Would it be better to limit the wildcards %a, %A, %F, %I, %d, %D, %L, %I to the 'simple' author and editor only, or should the wildcard supply the other types of author/editor if the 'simple' types do not exist?

   For me, returning only the 'simple' types make sense. It is possible to construct independent wildcards for the other types, if they are needed. (This may seem obvious, but, again, the code suggests someone entertained the cascade approach at one point, so worth mentioning).

[jlegewie]

Hi @depth-charge , @daaaaaaaaaniel and @ZBiener ,

I just merged @ZBiener pull request for this (thanks!). It would be hear from anyone who tests the version to see whether there are any problems. Right now, the version is just on GitHub...

Thanks!

[living-creatures]

This merged update does not appear to be installable by recreating the zipped .xpi file. I get an error in Zotero: 'The add-on "%S" could not be installed. It may be incompatible with this version of Zotero.'

This is for Zotero version 6.0.17

[ZBiener]

Have you tried install the .xpi file unzipped?

[living-creatures]

It doesn't seem to matter whether the .xpi file is installed zipped or unzipped; I receive the same error message in Zotero's Add-ons Manager.

[ZBiener]

hmmm. I can't replicate this. I'm on the latest MacOS, with compilers installed through homebrew. I download the Zip of the entire repository, run "make" when in the repository's root directory, and the resulting .xpi works fine. I won't have time to troubleshoot more until next Tue., but if you tell me all the other relevant info for your install (OS, etc.), I might be able to look into it then, if I can get hold of an appropriate machine.

[living-creatures]

My apology: I was able to get make to work - it hadn't been configured correctly.

That said, the wildcards %d, %D, %l and %L still do not appear to output anything in the Renaming Rules of ZotFile's preferences.

For example, the renaming rule: {%L.}{ (%y).}{ %t} should output a filename similar to: LastF. (2022). The title of my document

Instead, this renaming rule simply outputs: (2022). The title of my document

[jlegewie]

The renaming rule works for me. Are you sure what the item has an editor? I get your result when I try the renaming rule with an item that has no defined editor.

[living-creatures]

Weirdly the renaming rule will not work with %L even if the item has an editor (as one example), but will with %F (%F seems to pick up either the editor or primary author). Just to be clear, this is ZotFile 5.1.2.999