https://forums.zotero.org/discussion/96138/lost-content-in-tag-selector
An entered character from the CJK_COMPATIBILITY_IDEOGRAPHS block (char
code 63834, or similar) was normalized to the CJK_UNIFIED_IDEOGRAPHS
block (char code 35712), which then caused an expected key not to exist.
To fix, normalize colored tag values coming from the DB.
Handles items with an alternate field that maps to title (like cases)
and items for which the title is usually filled in by updateDisplayTitle()
(like letters).
This is a confusing, bad option, which was already disabled in groups,
and this removes it from personal libraries as well. People seem to be
using it mainly because they think annotations are locked into Zotero if
they don't, which is causing them to ask for this to be done
automatically on every edit, which we don't do because it would result
in constant file syncing and file conflicts [1].
We provide multiple export options for exporting PDFs with annotations,
and people can use those when sharing a file with people who don't use
Zotero. Otherwise, if storing annotations in the file is a priority,
they can use an external reader that's not designed to be tightly
integrated into Zotero.
(As a rare hack, it's of course also possible to export the PDF with
annotations, replace the original file, and import the annotations.)
[1] https://www.zotero.org/support/kb/annotations_in_database
91faa73b19 made getString return the key
instead of throwing on non-en-US locales, so we check if the getString
result is equal to the key even if it doesn't throw.
Fixes#2472.
Just show the key
We still merge strings before pushing betas, but this means it won't
crash for source builds, or if we forget. Not sure why we didn't do this
15 years ago.
`OS.Path.join()` on Windows throws if an integer is passed. Seems like
this would happen on another computer whenever an image annotation is
deleted in a group?
Follow-up to 734057ff9b
This was supposed to allow ZotFile to continue to work but 1) it
contained a bug and 2) another transaction messed things up for ZotFile
anyway, so we'll just fix this in jlegewie/zotfile#593.
The call to _window.addEventListener() might have been causing an error
when _window was null or undefined (no main Zotero window could be
found), which would prevent _windowLoading from being set to true and
the window from being added to the ProgressWindowSet, which might have
caused unpredictable behavior when positioning windows later on.
I could only briefly reproduce the issue, so this is just one idea. The
call to addEventListener on a potentially null _window was definitely a
bug but I don't know if it caused the crash.
