but that just seems like one more way in which attachment titles are/can be helpful? Since filenames are constructed from item metadata, they couldn't include that information.
To be clear, what dstillman mentions (and IIRC has since confirmed as planned) would be an _option_ to display filenames instead of attachment titles (thus mimicking ZotFile behavior in Zotero =<6), and I'd assume not the default option (which would be to display attachment titles as previously).
@adamsmith absolutely attachment titles are useful! But they're only useful within the Zotero app interface. When working with attachment files from Zotero in other applications, the fact that (afaik) there's no {{ attachmentTitle }} variable (as proposed by dstillman) means that it's difficult to distinguish one chapter from another within the same book when working with files in other applications—and @erazlogo's use case 1. was about working in other applications.
Right, but what people here are suggesting (and the current ZotFile behavior they're using and have not complained about as far as I know) is to set the attachment title to the (ZotFile-generated) filename which would make this worse, not better.
@adamsmith All I am asking for is an OPTION to set Attachment file title according to the citation information, not to do that automatically on import. Currently the only way to change Attachment Title is by typing it manually, one attachment at a time. There is already a script to change file name according to citation information. It could be adapted to attachment title. It doesn't seem too much work to accommodate me and a considerable number of other users here and on a few other threads who are asking for this feature.
@erazlogo: You didn't actually respond to adamsmith's points. As we've said repeatedly, we're going to add the option to display the filename in the items list instead of the attachment title. If you don't find the attachment titles useful, you can then ignore them. (And compared to Zotero 6, you'll no longer need to run some tedious manual step just to get the attachment title to match the filename.) If that option somehow wouldn't fulfill your needs, you'd have to explain why. Duplicating citation info in another field makes no sense to us, so it's not something we're planning to implement.
You are telling me that the way I use Zotero is "confusing" (adamsmith) and "makes no sense" (dstillman). I am not responding to these comments. These are not logical points. They are just dismissive insults.
If a user drags a PDF from the file system the attachment title does get changed according to the filename in the latest Zotero 7 version. But a user cannot do the same with files imported from online databases. That is indeed "confusing" and "makes no sense." Then the attachment title should be "PDF added by user" to be consistent.
After upcoming changes, you'll have a variable (filename) that users will be able to display in the list view but will not be able to find via search. That will also be "confusing" and will not "make sense." If data is useful enough to be displayed, it should be available via search.
@erazlogo: I'm not sure why you're interacting with us this way? Someone disagreeing with you, explaining their viewpoint, or asking for clarification isn't being rude or dismissive, and they're certainly not insulting you. You've been around long enough to know that we don't just make changes to Zotero because people demand them — we make changes when people engage with us and convince us with well-reasoned arguments.
@adamsmith and I are both genuinely trying to understand why the option we've repeatedly said we'll be adding would be insufficient for your usage.
If a user drags a PDF from the file system the Attachment Title does get changed according to the file name in the latest Zotero 7 version. […] Then the attachment title should be "PDF added by user" or something.
It's doesn't "get changed" — when it's a standalone file, there's nothing else to call it. But yes, we're likely going to start changing the attachment title to just "PDF" once metadata retrieval is run and a parent item is created if the title still matches the filename, because we don't think there's any point in duplicating either the filename or the parent row.
Again, though, you will be able to set it to show filenames in the items list and never think about attachment titles again if you don't want to. I'd also just like to reiterate that the only way you would've been getting an attachment title that matched the filename in Zotero 6 was by running a manual operation on every single file you saved from the web (or by using a plugin, which is out of scope for this discussion). And while I assume you understood this, I think many people genuinely did not understand that files saved from the web have always been automatically renamed and only got into the habit of running it manually because they thought they were renaming the file. This is the kind of tedium we try to help people save themselves from, and our proposed setting will do that while producing the same result in the items list.
But if that's not sufficient for you for some reason, you'd have to explain why.
After upcoming changes, you'll have a variable (filename) that users will be able to display in the list view but will not be able to find via search.
I mean, we can obviously change All Fields & Tags to match the filename as well and add a search condition for that in Advanced Search. But @adamsmith asked what the actual use case is for matching a child attachment by filename when it's almost certainly named using the parent item metadata, and you refused to answer.
It's doesn't "get changed" — when it's a standalone file, there's nothing else to call it. But yes, we're likely going to start changing the attachment title to just "PDF" once metadata retrieval is run and a parent item is created if the title still matches the filename, because we don't think there's any point in duplicating either the filename or the parent row.
I am not talking about a standalone file, but when an item exists already and I drag the PDF over it to create an attachment. The attachment title is then renamed according to item metadata, which makes it seem that this renaming is an expected behavior, but actually it is not.
@adamsmith asked what the actual use case is for matching a child attachment by filename when it's almost certainly named using the parent item metadata, and you refused to answer.
Users will still be able to change the attachment titles and filenames manually, no? In that case, it may be necessary to search for the filename.
With the old usage, I could match the two variables, and then display (in the list view) and search for the attachment title, knowing that I would see and find the filename. Now that the two fields are distinct by design and I cannot match them nor search for the filename, I no longer have this functionality and I will miss it.
I will adapt of course, and being able to display the filename in the list view will be great, thanks! But you are in fact taking away user agency and functionality in this (admittedly, minor) case.
I am not talking about a standalone file, but when an item exists already and I drag the PDF over it to create an attachment. The attachment then is renamed according to item metadata, which makes it seem that this renaming is an expected behavior, but actually it is not.
Oh, OK. The behavior is actually a little more complicated there. If it's the first PDF, we rename the file (on the assumption that it's the primary file), and if it's not, we don't (on the assumption that it might be supplementary materials). So the first case would be equivalent to a standalone file being recognized and we should similarly set the title to "PDF", and the second case should use the filename because that's all there is.
It's true, I never had to deal with the fact that the two variables are different.
But you did, though. Again, files saved from the web have always been renamed, and have always had a translator-set title. As we've explained, the fact that Rename File from Parent Metadata — which had zero effect on the filename of a file saved from the web — changed the title as well was essentially a bug. That's what we've fixed in Z7.
Now that the two fields are distinct by design and I cannot match them nor search for the filename, I no longer have this functionality and I will miss it.
But the fields have always been distinct by design! You were performing an extra manual step that didn't actually do what it said it was doing but had the incorrect side effect of making them the same. The fact that All Fields & Tags didn't match the filename as well has always been a bit of an oversight, specifically because in the default case the filename was different from the title. We'll fix that along with adding the setting to show filenames in the list. In practice, though, this just almost never matters, because when the filename is named after the metadata it's easier to just search for the parent. That's what @adamsmith was getting at above.
Thank you for adding filename to the search in the future--that would get me back to the functionality I need. And yes, you are right, that is definitely a better solution than the manual renaming of attachment titles.
In practice, though, this just almost never matters, because when the filename is named after the metadata it's easier to just search for the parent. That's what @adamsmith was getting at above.
I understood what @adamsmith was getting at, but I prefer to be able to search for the filename in those rare cases.
@dstillman here's an actual use case for using search to match an item by filename. Using the browser extension to import many chapters in the same book from direct.mit.edu/ is a tedious process (at least the way I do it, which I believe is the least tedious way) where I open the chapter PDF for each chapter in the browser then import the PDF. Zotero (usually) fails to recognize the book/chapter metadata or automatically rename, so each chapter ends up with a filename like "9780262305358_fb.pdf". It's tedious enough to go through and manually give each PDF a sensible title that reflects the chapter's proper name, and doubly tedious to do it twice to give it a proper filename too. So usually I just fix the title and leave the nonsensical filename intact. A few months later, let's say I run a search for PDF files on my computer using ie. macOS Finder or Spotlight or another app, and I start reading 9780262305358_fb.pdf, and then I want to find that file in Zotero, but I don't know what book it came from. That can be challenging.
The latest build (7.0.0-beta.102+e6b5ba60d) is even more user-unfriendly on file title/file name. When I drag a file into Zotero, that random filename (audio1025205441, etc.) becomes the file title and it can ONLY be changed manually. Can you explain to me the logic of that?
I have to rename the filename according to the citation via Zotero and then manually copy that name to the file title field. This extra manual step makes no sense. Please allow for automatic changing of file titles according to citation.
@erazlogo: By default, file renaming only applies to PDFs and EPUBs, which are publication file types where we can be pretty confident they represent the metadata of the parent item. That's not the case for other file types — e.g., if someone drags a Word or Excel file, or some data file, it very likely wouldn't be appropriate to rename them in the same way. One could maybe make the case for renaming image and/or audio files by default, but we don't currently do that. If you always want audio files to be renamed, you can adjust the extensions.zotero.autoRenameFiles.fileTypes hidden pref. (That currently takes content-type strings, but we should probably change it to take file extensions. Start a new thread if you're having trouble with that.)
When you drag a PDF or EPUB as the first file of its type, we set the title to "PDF" or "EPUB". If we enabled renaming of image or audio files by default, or if we made a visible setting to enable those, those could get similar default titles. In the meantime, I would encourage you to give those attachments similar titles that actually explain what they are, not that pointlessly duplicate the parent item metadata.
We've made very clear our belief that setting the title to the file is a bad idea, so we're not going to facilitate that.
adjust the extensions.zotero.autoRenameFiles.fileTypes hidden pref
Thank you, that helps a lot! I got it to work, and this feature actually still renames the file title, so I am all set for now.
General point: Right now Zotero (in the file title feature at least) is biased toward text--PDF and EPUB are built in, the rest is completely ignored. Interview item type will often have audio or video attachments; Audio Recording or Radio Broadcast item types will have audio attachments; Artwork item type will have image attachments; Film or Video Recording item types will have video attachments. These should get the same respect as the text files.
In the meantime, I would encourage you to give those attachments similar titles that actually explain what they are, not that pointlessly duplicate the parent item metadata.
Here you are engineering Zotero to make users do more manual entry. I hope you realize how much mind-numbing drone work that entails. I have done 70+ interviews for my current project, all audio, and I have 100+ more to look forward to, and I am not interested in renaming Zoom-generated file names manually for every interview to get meaningful file titles on import. Automatic renaming of filename on import gets me all the explanation I need (interviewee name + date + file type).
When you drag a PDF or EPUB as the first file of its type, we set the title to "PDF" or "EPUB".
Here you are basically setting the file extension as the placeholder for the "file title." Then, in keeping with your system, "file title" should simply be set to the file extension when a file is imported from the file system, whatever it is (pdf, m4a, mkv, etc), with the expectation that the user will change it to something descriptive manually if necessary. You seem to assume that the user will change the placeholder to a descriptive title, but in most cases, the user will not need to change it. It only needs to be changed if there are multiple text files or multiple sound/video clips for the same item, or if the file represents a part of the work--a clip or an excerpt.
I see in the new Z7 version, you can set image, audio, and video files to be automatically renamed, and the file titles are automatically set to "Audio," etc. Thank you!!
After updating to Zotero 7 (Ubuntu version) the file name is no longer updated when I click "Rename file from parent metadata". This is very irritating, why does the file name not change? This makes it not possible to for instance search on the file name and find the item in the library any longer. Please
This thread is from the Zotero 7 beta period and has various outdated information, so I'm closing it to avoid future confusion. Please open a new thread with further questions or feedback.
Upgrade Storage
To be clear, what dstillman mentions (and IIRC has since confirmed as planned) would be an _option_ to display filenames instead of attachment titles (thus mimicking ZotFile behavior in Zotero =<6), and I'd assume not the default option (which would be to display attachment titles as previously).
{{ attachmentTitle }}variable (as proposed by dstillman) means that it's difficult to distinguish one chapter from another within the same book when working with files in other applications—and @erazlogo's use case 1. was about working in other applications.If a user drags a PDF from the file system the attachment title does get changed according to the filename in the latest Zotero 7 version. But a user cannot do the same with files imported from online databases. That is indeed "confusing" and "makes no sense." Then the attachment title should be "PDF added by user" to be consistent.
After upcoming changes, you'll have a variable (filename) that users will be able to display in the list view but will not be able to find via search. That will also be "confusing" and will not "make sense." If data is useful enough to be displayed, it should be available via search.
@adamsmith and I are both genuinely trying to understand why the option we've repeatedly said we'll be adding would be insufficient for your usage. It's doesn't "get changed" — when it's a standalone file, there's nothing else to call it. But yes, we're likely going to start changing the attachment title to just "PDF" once metadata retrieval is run and a parent item is created if the title still matches the filename, because we don't think there's any point in duplicating either the filename or the parent row.
Again, though, you will be able to set it to show filenames in the items list and never think about attachment titles again if you don't want to. I'd also just like to reiterate that the only way you would've been getting an attachment title that matched the filename in Zotero 6 was by running a manual operation on every single file you saved from the web (or by using a plugin, which is out of scope for this discussion). And while I assume you understood this, I think many people genuinely did not understand that files saved from the web have always been automatically renamed and only got into the habit of running it manually because they thought they were renaming the file. This is the kind of tedium we try to help people save themselves from, and our proposed setting will do that while producing the same result in the items list.
But if that's not sufficient for you for some reason, you'd have to explain why.
With the old usage, I could match the two variables, and then display (in the list view) and search for the attachment title, knowing that I would see and find the filename. Now that the two fields are distinct by design and I cannot match them nor search for the filename, I no longer have this functionality and I will miss it.
I will adapt of course, and being able to display the filename in the list view will be great, thanks! But you are in fact taking away user agency and functionality in this (admittedly, minor) case.
I have to rename the filename according to the citation via Zotero and then manually copy that name to the file title field. This extra manual step makes no sense. Please allow for automatic changing of file titles according to citation.
extensions.zotero.autoRenameFiles.fileTypeshidden pref. (That currently takes content-type strings, but we should probably change it to take file extensions. Start a new thread if you're having trouble with that.)When you drag a PDF or EPUB as the first file of its type, we set the title to "PDF" or "EPUB". If we enabled renaming of image or audio files by default, or if we made a visible setting to enable those, those could get similar default titles. In the meantime, I would encourage you to give those attachments similar titles that actually explain what they are, not that pointlessly duplicate the parent item metadata.
We've made very clear our belief that setting the title to the file is a bad idea, so we're not going to facilitate that.
General point:
Right now Zotero (in the file title feature at least) is biased toward text--PDF and EPUB are built in, the rest is completely ignored. Interview item type will often have audio or video attachments; Audio Recording or Radio Broadcast item types will have audio attachments; Artwork item type will have image attachments; Film or Video Recording item types will have video attachments. These should get the same respect as the text files. Here you are engineering Zotero to make users do more manual entry. I hope you realize how much mind-numbing drone work that entails. I have done 70+ interviews for my current project, all audio, and I have 100+ more to look forward to, and I am not interested in renaming Zoom-generated file names manually for every interview to get meaningful file titles on import. Automatic renaming of filename on import gets me all the explanation I need (interviewee name + date + file type). Here you are basically setting the file extension as the placeholder for the "file title." Then, in keeping with your system, "file title" should simply be set to the file extension when a file is imported from the file system, whatever it is (pdf, m4a, mkv, etc), with the expectation that the user will change it to something descriptive manually if necessary. You seem to assume that the user will change the placeholder to a descriptive title, but in most cases, the user will not need to change it. It only needs to be changed if there are multiple text files or multiple sound/video clips for the same item, or if the file represents a part of the work--a clip or an excerpt.
In a separate post, I also asked to add an option for filenames to be displayed in the Zotero list view instead of file titles.
This thread is from the Zotero 7 beta period and has various outdated information, so I'm closing it to avoid future confusion. Please open a new thread with further questions or feedback.