All public and development styles are now available from this page:
The individual styles are linked from there at their new permanent URIs,
served as text/xml. There are also "[Install]" links that serve the
files as text/x-csl, which Zotero 1.0.2 and up (and the current branch
dev build) will automatically install. Installing a CSL will overwrite
an existing one in your Zotero DB with the same URI. Zotero 1.0.2 will
also automatically replace the ten existing styles whose URIs have
changed when they are next updated via the repository (though not when
the new versions are installed manually from that page).
There won't be a way to delete individual CSLs via the UI in 1.0.2, but
the "Rebuild Translators Table" button in the Advanced section of the
Zotero prefs has been changed to "Reset Translators and Styles" and will
now delete all installed CSLs and reinstall the latest from the repo.
All users with Zotero SVN/Trac accounts
(https://www.zotero.org/dev/trac_access) can commit styles to
https://www.zotero.org/svn/extension/trunk/csl/. New and modified styles
will automatically show up in the Dev Styles section of the above page.
After committing a new style, please start a new thread in the
Import/Export section of the Zotero forums pointing people to
http://www.zotero.org/styles and asking for feedback. After Zotero 1.0.2
is out, people will be able to use the install functionality, but until
then they'll need to view the style and copy it into
chrome://zotero/content/tools/csledit.xul.
After a style has received enough feedback and any necessary changes
have been made, we'll make it public, and it will automatically become
available to Zotero clients.
For Zotero 1.5, we'll look into switching the repository to an
Atom-based system and adding support for multiple repositories, as Bruce
has suggested.
A few other things regarding committing styles:
- Files that don't parse as XML will be rejected automatically.
- Committed styles will be checked against the new (trunk) and old
versions of the CSL schema, and old-style and invalid styles will be
noted as such on the page. All styles committed should validate against
the latest trunk schema.
- Dev styles will have "(dev)" appended to their titles automatically
when viewed/installed.
- Leave <updated/> empty. A timestamp will be generated automatically.
We've created a new system to streamline the process of contributing,
testing, and editing the CSL files used in Zotero.
All public and development styles are now available from this page:
http://www.zotero.org/styles
The individual styles are linked from there at their new permanent URIs,
served as text/xml. There are also "[Install]" links that serve the
files as text/x-csl, which Zotero 1.0.2 and up (and the current branch
dev build) will automatically install. Installing a CSL will overwrite
an existing one in your Zotero DB with the same URI. Zotero 1.0.2 will
also automatically replace the ten existing styles whose URIs have
changed when they are next updated via the repository (though not when
the new versions are installed manually from that page).
There won't be a way to delete individual CSLs via the UI in 1.0.2, but
the "Rebuild Translators Table" button in the Advanced section of the
Zotero prefs has been changed to "Reset Translators and Styles" and will
now delete all installed CSLs and reinstall the latest from the repo.
All users with Zotero SVN/Trac accounts
( https://www.zotero.org/dev/trac_access) can commit styles to
That would be great. Let me know if you run into any problems.
Excellent; nice job Dan!
Bruce
> - Leave <updated/> empty. A timestamp will be generated automatically.
And I presume if the element is filled it will simply get updated? If
yes, you might tweak the description of this process to make that clear.
Bruce
<html>
<head>
<style>
The styling doesn't get loaded, it seems, without the text/css attribute
on the style element, and the default namespace isn't on the root.
Bruce
Bruce
Currently, no--<updated> is only changed if the value is blank. But
there's probably not much need to be able to set an explicit timestamp,
so I can change it to update regardless. As Codec notes, requiring an
empty element is annoying, as it makes styles invalid while editing. I
was mainly just trying to save people from feeling any sort of obsessive
need to update the timestamp before committing each time.
I think auto-updating is the ideal approach since a) the field *should*
be updated anytime a style change gets committed, and b) I know I'm too
lazy to want to do it myself, and presume I'm not alone ;-)
Bruce