Upgrade StorageInclude tags in bookmark export
Currently when I export the library, I get just a giant list of links.
That is not ideal.
I would like for the exported bookmarks to preserve the tags, like for example Firefox does.
That is not ideal.
I would like for the exported bookmarks to preserve the tags, like for example Firefox does.
Not a fan of being locked in.
https://github.com/zotero/translators/blob/1bc64bd22d341e12d847ecf012de7864f7dc74a4/Bookmarks.js#L242
That's surprising.
And sad :\
If there's something specific you're trying to do, just explain it and we can recommend an approach. But you seem to have no idea what this file format is.
https://support.mozilla.org/en-US/kb/import-bookmarks-html-file
https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/aa753582(v=vs.85)
https://support.apple.com/guide/safari/import-bookmarks-and-passwords-ibrw1015/mac#ibrw62da31ab
https://support.google.com/chrome/answer/96816
Sure, it's ancient and it's got its downsides, but it's still actively used everywhere by the looks of it, so it's the only universal format, unless there's another translator that produces a format I can freely feed to most other archival tools or browsers.
>If tags were added to this translator they wouldn't even be visible — they're stored in attributes.
They're definitely visible.
Zotero happily imported and organized everything with a Firefox-produced HTML.
Problem is it loses them during export.
I'm trying to not get locked in.
If I ever decide to move from Zotero or have to use another tool for whatever reason, I don't want to be stuck.
<DT><A HREF="[…]" […] TAGS="foo bar">It's possible some other browser puts them in the visible text as well, but that's not defined anywhere and not what actually gets imported.
Adding tags to an attribute in the Bookmarks.js translator would be trivial, and again, we'll happily take a patch for it. But the whole premise here is misguided. The bookmarks format would be incredible lossy — it's absolutely not any sort of protection against lock-in. Zotero supports countless standard bibliographic formats that include vastly more data (e.g., BibTeX or RIS).
But there's also no reason to worry about this until you're actually moving your data somewhere. Zotero has been around for 15+ years, is open source, stores data in an open SQLite database, and has built-in support for a couple dozen export formats. Your data isn't going to be locked in.
Import a Firefox-exported HTML into Zotero, and all the tags are imported and correctly labeled.
Meaning Zotero is obviously able to deal with HTML tags on import, but unable to deal with them on export.
This inconsistency is what this whole post is about.
Just because it's stored in an attribute doesn't mean it's invisible.
You can open the HTML in any text editor (HTML is just a marked up plaintext file) and they will all be there.
The only time it would be invisible is when you open it as a webpage (which is obviously not applicable here).
The "visible text" area is for the Title field.
The attribute is the proper place for the tags, along with the URL and any other additional metadata.
>Zotero supports countless standard bibliographic formats that include vastly more data (e.g., BibTeX or RIS).
Neither Chrome, nor Firefox, nor tools like Archivebox support BibTeX or RIS though.
>But there's also no reason to worry about this until you're actually moving your data somewhere.
That's like getting an iPhone, then years later wondering why all the iMessage contacts and data won't transfer to your new Android phone.
I'd rather worry about that stuff in advance than be stuck in a walled garden.
Note that Apple have also been around for 15+ years.
Calling Zotero a "walled garden" or relating this to "lock in" is absurd — again, we support countless export formats.
There's nothing more to say on this. It's a one-line change to add tags to the export format. I've created a ticket for it. If you know what an HTML attribute is, you can probably just do it yourself and submit a patch. If not, someone else might do it. But the bookmarks format supports a minuscule subset of the data people store in Zotero, so this just isn't remotely on anyone's priority list.