An integrated find and replace option in Zotero?

Would it be possible to construct such a facility in Zotero? It would make life a lot easier. Excuse me if it already exists, but I haven't been able to locate it. Yours Sincerely Erik Schwägermann
  • Do you mean an option to batch edit multiple items at once (e.g., replace all instances of "The International Journal of Human Resource Management" with "International Journal of Human Resource Management")? If so, it's not currently possible in a user-friendly way (in Zotero for Firefox, you can use the Javascript API to batch edit https://www.zotero.org/support/dev/client_coding/javascript_api#batch_editing).

    An easier-to-use batch editing feature is planned for Zotero in the medium term (I believe the plan is for Zotero 5.2).
  • edited August 30, 2017
    I am looking forward to the batch editing feature!

    In the meantime, I tried following the instructions for batch editing linked above without success. I set the oldValue and newValue to "Escherichia coli" and "<i>Escherichia coli</i>", in order to italicize all instances of the name appearing in titles, but when I run the code it returns "No items found". I tried changing the fieldName to "title", which didn't work either. Any suggestions?

    I am using Scratchpad in Browser mode. Zotero 4.0.29.22; Firefox 55.0.3

  • If I recall correctly, Dan has mentioned that batch editing is a fairly high priority for upcoming versions of Zotero (but no ETA on that or promises that I'm remembering accurately).

    The script you are currently is likely failing because the sample script you are modifying uses the 'is' match condition, rather than 'contains'. This means that it is looking for titles that are only the words "Escherichia coli", so obviously that won't work. To do what you are hoping to do, you would need to use regular expressions in the search code. So, you would search for 'title' 'contains' 'Escherichia coli', then set newValue to the result of a regex function that returns all of the stuff before "Escherichia coli", the revised "Escherichia coli", and all the stuff after "Escherichia coli".

    See the fourth post here for an example of using regex in a Zotero search query:
    https://forums.zotero.org/discussion/7707/find-and-replace-on-multiple-items

    You can google around for a guide on how to write javascript regular expressions.
  • Thank you @bwiernik ! That makes sense!
  • Yes, batch editing would be great! I often add books to my Zotero database from WorldCat, and the format of the language field varies a lot (sometimes English, sometimes EN, etc.). If I don't notice that it's "English" and change it to "EN," then the entry isn't formatted correctly in the footnotes (i.e. words in the title aren't capitalized). I currently have dozens of entries like that saved, and have to go back and change the language field manually every time I come across one. I know I can search for "English," but then there's no way to replace that field, so it doesn't do me a lot of good. A batch edit feature would solve this problem.
  • Here I go again. While I know that styles can take care of this issue; I'd be really pleased if this could be done upon import. I use a center display that includes the language field. I find it disconcerting to have entries that are different lengths. As I offered once before. I'm willing to pay for this feature.
  • I agree with DWL-SDCA that some way of standardizing the language field on import would be ideal. Alternatively, how hard would it be for Zotero to recognize multiple formats for language (e.g. English, english, EN, en...)? This wouldn't solve the visual problem of different lengths, but it would allow Zotero to format titles properly according to language, regardless of what format was used on the website the item was initially saved from (e.g. WorldCat vs. Amazon vs. university library, etc.). Of course, this still wouldn't retroactively solve the problem that if I have dozens of entries with "English" in the language field, I have to manually convert them to "EN." In that respect, the ideal fix in the long term would be both a standardizing function on import and a batch replace function for existing entries.
  • Recognizing full-Word language descriptions would be basically impossible, as that would entail recognizing not only English language names, but also names in other languages and other lengths of abbreviations (e.g., eng, engl, etc.). The ISO codes are really the only way to standardize languages for use by the citation processor. Ideally, the Language field would be replaced by a drop down menu that shows the full language name but stores the underlying language code.
  • bweirnik, true, I hadn't thought about all the variants it would have to recognize, though it would be nice if it could at least recognize the full name of any language both in English and in the language itself (e.g. German and Deutsch). There would still be plenty of variants unaccounted for, but that would certainly cover a lot of them. I also agree that a drop-down would be helpful, but what would happen when you import an item that doesn't use the ISO code? Would it just leave the field blank, or prompt you to select the language? Or would it be possible to set a default language for all imported citations that don't have a code, so that e.g. if you know most of your sources are in English you could just set it to default to EN? I wish the formats on WorldCat and other catalogs (and JSTOR, etc.) were more standardized, that's really the source of the problem, I realize that dealing with a mass of non-standardized data makes Zotero's job harder.
  • edited September 10, 2017
    Recognizing full-word language descriptions would be basically impossible...

    Not really. A parser would need the standard ISO language name (this happens to be in English); the name used by those who use the language (not straightforward because sometimes there may be more than one [but fewer than several]; ISO 639-1; ISO-639-2B; ISO-639-2T; and ISO-639-3. There are no conflicting duplicates. While there will be potential character set / character encoding problems these are likely to be relatively rare.

    The vast majority of publishers of books and journals, agencies and NGOs that publish reports, universities that publish theses, and entities that maintain databases all follow their standard (one of the above).

    This would only leave us with the problem of publishers that do not provide metadata containing language information. But that is a different issue entirely.

    edit: Yes, I'm ignoring regional subtags (en-uk, en-us, fr-ca, etc) but having that info within metadata is rare.
Sign In or Register to comment.