Multi-part publications saved from the web will have appropriate titles.
This is true, and it works correctly with Project MUSE in my tests.The problem is that even though the titles are named correctly, the filenames end up failing.I can fix the botched filenames by selecting all the attachments and running "Rename File from Parent Metadata," and that gives all the attachments identical filenames.This isn't the end of the world, but I wish there was a way to algorithmically transfer the information present in the title into the filename.This could be done if the custom filename format included a variable like
{{ attachmentTitle }}, as you originally suggested in a comment last year
188BET靠谱吗https://forums.zotero.org/discussion/comment/440331/#Comment_440331.But as far as I know, that variable hasn't been implemented yet, so the only way to bring information from the title into the filename is through manual operation.
The problem is that even though the titles are named correctly, the filenames end up failing
Can you explain what you mean by this?
Re:
{{ attachmentTitle }}, the problem is that there needs to be some way to do this only for certain attachments, since you probably don't want to use that variable if the title is, say, "PDF".So one option we're considering would be to add a way to check for certain strings in the attachment title, so that you could exclude "PDF"/"Accepted Version"/"Submitted Version"/etc.and only use
{{ attachmentTitle }}for an actual chapter/etc.title assigned by a translator or manual entry.
Re: {{ attachmentTitle }} – great news to hear it's still on the table!That all sounds good to me.
Re: Botched titles when saving multiple entries from Project MUSE - here's an example
https://muse.jhu.edu/pub/4/edited_volume/book/123684.188BET靠谱吗When I add it to Zotero with the browser extension, every chapter is properly downloaded and added to the new item in Zotero, and each chapter is given the proper title.The problem is, each chapter's filename is automatically set to
2024 - .pdffor no good reason.Actually it's probably an issue with my custom filename format.When the translator pulls the metadata for that item from Project MUSE, it misses the author (the author is empty), and my custom filename format breaks when the author is empty.
So I have to add the author manually, and then run "Rename File from Parent Metadata." And since there's currently no {{ attachmentTitle }} variable, every attachment under that item entry ends up with identical filenames.
I acknowledge it's my own fault that the custom filename format I use isn't resilient enough to handle scenarios with no author.But the bigger issue is that for any number of different reasons, a user might download attachments and then after the fact edit/correct the item's metadata.And I would hope that those changes/corrections would propagate through to update the filename with as little repetitive manual editing as possible.
Upgrade Storage
{{ attachmentTitle }}, as you originally suggested in a comment last year 188BET靠谱吗https://forums.zotero.org/discussion/comment/440331/#Comment_440331.But as far as I know, that variable hasn't been implemented yet, so the only way to bring information from the title into the filename is through manual operation.Re:
{{ attachmentTitle }}, the problem is that there needs to be some way to do this only for certain attachments, since you probably don't want to use that variable if the title is, say, "PDF".So one option we're considering would be to add a way to check for certain strings in the attachment title, so that you could exclude "PDF"/"Accepted Version"/"Submitted Version"/etc.and only use{{ attachmentTitle }}for an actual chapter/etc.title assigned by a translator or manual entry.Re: Botched titles when saving multiple entries from Project MUSE - here's an example https://muse.jhu.edu/pub/4/edited_volume/book/123684.188BET靠谱吗When I add it to Zotero with the browser extension, every chapter is properly downloaded and added to the new item in Zotero, and each chapter is given the proper title.The problem is, each chapter's filename is automatically set to
2024 - .pdffor no good reason.Actually it's probably an issue with my custom filename format.When the translator pulls the metadata for that item from Project MUSE, it misses the author (the author is empty), and my custom filename format breaks when the author is empty.{{ if authors == "" }}{{ editors join=" & " }}{{ year prefix=" " }} - {{ shortTitle case="title" }}{{ elseif shortTitle != "" }}{{ authors join=" & " }}{{ year prefix=" " }} - {{ shortTitle case="title" }}{{ elseif shortTitle == "" }}{{ authors join=" & " }}{{ year prefix=" " }} - {{ title case="title" }}{{ else }}{{ citationKey prefix=" @" }}{{ endif }}
So I have to add the author manually, and then run "Rename File from Parent Metadata." And since there's currently no {{ attachmentTitle }} variable, every attachment under that item entry ends up with identical filenames.
I acknowledge it's my own fault that the custom filename format I use isn't resilient enough to handle scenarios with no author.But the bigger issue is that for any number of different reasons, a user might download attachments and then after the fact edit/correct the item's metadata.And I would hope that those changes/corrections would propagate through to update the filename with as little repetitive manual editing as possible.