When resolving duplicates, I often get a situation where neither of the two duplicates has the correct information in a given field - for instance - both are missing a subtitle. All I can do is either to use left, right, or none. But none of these options do the job - I need a fourth option, namely “use new” or something like that. Another example is one where both duplicates are missing the same information - for instance address. It would be really handy to add the information upon resolving the duplicate. I know that this would make the duplicate resolution somewhat more heavy-handed, but I would just find so very useful.
I suggest you merge your entry (e.g. decide for one ) and then do a lookup information from doi/etc in the entry editor. If you are lucky, you might get the needed extra information. In such cases the merge dialog is also shown.
Thanks for the suggestion. What you suggest would be fine for, say, a single or very few duplicates. But the thing is, I have two large bibliographies (one from collection of papers A, another from collection B, each having around 700 references). I want to create one out of them, without duplicates. At the same time, it would be really handy to use the de-duplication process to place a note (into a field specialized for that) that that particular reference is cited in both A and B. (I’m an editor and need to keep track of what is cited where.) Now, if I have 50 duplicates, I can handle them by merging them, one by one, but then I have no post-hoc way of finding out which ones used to be duplicates, in order for me to edit the field. Of course, I could take notes on a piece of paper, or into an auxiliary text file, but that just seems tedious…
Essentially, what I would be after, would be a really simple thing. Not just having a choice between
left - none - right
but
left - none - right - other
where would could rewrite both left and right by new contents, which would come handy not just in my particular case, but also if neither left nor right are correct, but it’s also incorrect not to use that field…