(not sure it’s the best way to document it, but as long as it’s documented, I figured it’s better than nothing!).
Only issue is I don’t have a good way to systematically validate the style, as I typically use the web interface. If one of you is able to check all the dependent styles added, that would be great. Please let me know if you spot some issues, as I will then modify my script accordindly to take into account the missing bits. For instance, I escape the ‘&’ in the titles, but maybe I missed some other character. Or something is systematically wrong with the generation of the identifier or file name.
Thanks for your work on this. I do wonder whether it makes sense to
have quite so many dependent styles in the repository though.
I have been wondering if it would make sense to ‘push’ users and
publications to use well known existing styles more.
I’ll have to bite the bullet at some point, though, I agree!
Less painful that dealing with problems arising if your users download
styles with bugs that would be caught by a validator though.
Thanks for your work on this. I do wonder whether it makes sense to
have quite so many dependent styles in the repository though.
I have been wondering if it would make sense to ‘push’ users and
publications to use well known existing styles more.
I don’t think pushing users is an options - if you submit an article
to a given journal, you need to make sure to follow that journal’s
citation style. Dependent styles help users identify these styles -
you can’t really expect a user to know that a given style is, say
“Elsevier’s Harvard with Titles”.
There is also the fact that Endnote’s 5000 or so styles are still
being held up as proof that they provide users with oh so many options
dependent styles (which I assume Endnote uses in some way, too) help
us compete with that.
Finally, I don’t see a downside - on Zotero’s repository you can
remove dependent styles with one click, it’d be easy for you to
implement the same at Mendeley.
As for pushing publishers - sure, that’d be great. There are way too
many different citation styles. But that didn’t even work when there
weren’t good options to automate that, so I don’t really see how we
(or anyone else) is going to convince publishers now.
I’ll have to bite the bullet at some point, though, I agree!
Less painful that dealing with problems arising if your users download
styles with bugs that would be caught by a validator though.
while I agree that styles should be validated before being committed
(maybe use a pull request if you can’t validate?), there are a lot of
people watching the repository - we’d spot invalid styles within hours
and fix it. Also, again, I don’t know how you handle that at Mendeley,
but on the Zotero repo invalid styles are marked as such - you could
easily do the same.
Just a heads-up that Rintze and I started looking into automating tests (validation is among them I believe) using travis-ci – once we have this set-up we can be notified whenever a style is submitted or changed that does not validate.
shows that the BioMed Central style is invalid and has been since June 30. The validation error is not severe (“medicinede” is an invalid category term) but it should still get fixed.
FWIW, like others here, I think that committing styles that haven’t been validated is a very bad idea. Installing a local validator is not very difficult.
Just to clarify things: I do validate the styles I submit (except those 235 styles, which is why I mentioned I had not, and requested help from this list). The BMC style was a copy of bmc-bioinformatics. I made the mistake of not validating it again. Sorry!
Somewhat related: it’s always a little time consuming for me to make sure
pull requests from other contributors contain valid styles. It basically
involves manually navigating to the raw CSL style files, and copy/pasting
their individual URLs to validator.nu. I just discovered that Travis CI,
which is a hosted continuous integration service which Sylvester has some
experience with using, now also seems to be able to test pull requests
before they are merged! See http://about.travis-ci.org/blog/announcing-pull-request-support/ . Travis
CI supports Java projects, so I have some hope we can use their service to
run the Jing validator.
Rintze
P.S. I fixed the BioMed Central style just now.On Mon, Jul 2, 2012 at 11:26 AM, Simon Kornblith <@Simon_Kornblith>wrote:
Thanks for your work on this. I do wonder whether it makes sense to
have quite so many dependent styles in the repository though.
I have been wondering if it would make sense to ‘push’ users and
publications to use well known existing styles more.
BMC is a great example of that: I was impressed all their journals follow the same guidelines. Unfortunately, no other publisher has such a systematically consistent format for references.
As for the users: one Papers user asked for the style for Malaria Journal. Should I have told him to use ‘BMC informatics’. And tell the same to every user that ask? I don’t think we should put the burden of figuring out which style to use I the user. Their goal is to write a paper, not to spend time figuring out why a colon is used, instead of a period in the references. In fact, nobody should care about this, but publishers do, unfortunately, for some weird reasons. So it’s not just a number battle with EndNote, it’s a usability issue. It really makes the user’s life better if the style for the journal they want is right there. I think.
As for the users: one Papers user asked for the style for Malaria Journal. Should I have told him to use ‘BMC informatics’. And tell the same to every user that ask? I don’t think we should put the burden of figuring out which style to use I the user.
Absolutely - that’s what I meant by "Dependent styles help users
identify these styles -
you can’t really expect a user to know that a given style is, say
“Elsevier’s Harvard with Titles”. The Endnote numbers battle is a
secondary (albeit IMHO not irrelevant) concern.
S.------
Sebastian Karcher
Ph.D. Candidate
Department of Political Science
Northwestern University
I think per-journal styles make a lot of sense from a user-point-of-view.
It might make sense to automatically append the parent style to the style
title to indicate the dependency, e.g. “Malaria Journal (BioMed Central)”,
but some CSL style titles are quite long as they are.
And yeah, a lot of sites that compare the different bibliographic reference
managers list the number of styles supported, so propping up the number
with dependent styles clearly helps with marketing CSL.
One thing where I think http://www.zotero.org/styles could do better is
highlighting a few high-quality styles, such as apa.csl . E.g. the old
repository had a separate section for “default styles” that shipped with
Zotero, which was handy when you weren’t looking for a journal-specific
style.
RintzeOn Mon, Jul 2, 2012 at 12:02 PM, Charles Parnot <@Charles_Parnot>wrote:
Dependent styles are just XML-encoded aliases, with some additional
metadata. So yeah, I don’t think we should worry about having too many
of them. If anything, we should encourage more (e.g. rather than a
journal create their own new one, just link to an existing one).
I’m happy to add something like that back, if someone can provide
phrasing and a list. In order to not complicate the UI too much, it
could just be another checkbox above/below “Show only unique styles”.
“Show most popular styles”? “Show most common styles”? “Show top styles”?
We don’t know which styles are most popular, so my vote would be for “top”.
Would a drop-down menu make more sense, since the options should probably
be mutually exclusive? Maybe “Show all styles” (default), “Show unique
styles only”, “Show top styles only”? Do you prefer a static list, or
should I add a JSON list in the styles repo with the style IDs of the top
styles?
Also, Dan, how do you feel about adding some interface elements to select
styles by locale?
> One thing where I think http://www.zotero.org/styles could do better
> is highlighting a few high-quality styles, such as apa.csl .
E.g. the
> old repository had a separate section for "default styles" that
> shipped with Zotero, which was handy when you weren't looking for a
> journal-specific style.
I'm happy to add something like that back, if someone can provide
phrasing and a list. In order to not complicate the UI too much, it
could just be another checkbox above/below "Show only unique styles".
"Show most popular styles"? "Show most common styles"? "Show top
styles"?
We don’t know which styles are most popular, so my vote would be for
“top”. Would a drop-down menu make more sense, since the options
should probably be mutually exclusive?
A drop-down or a radio group. The former would save more space, while
the latter would show all options. It’s fairly important that people see
that they can show only unique styles.
Maybe “Show all styles” (default), “Show unique styles only”, “Show
top styles only”? Do you prefer a static list, or should I add a JSON
list in the styles repo with the style IDs of the top styles?
Let’s just go with a static list for now.
Also, Dan, how do you feel about adding some interface elements to
select styles by locale?
A drop-down or a radio group. The former would save more space, while the
latter would show all options. It’s fairly important that people see that
they can show only unique styles.
Yes, a radio button group would probably be better.
how do you feel about adding some interface elements to select styles
by locale?
I added locales/locales.json at master · citation-style-language/locales · GitHub ,
which contains a translation table between locale codes and human-readable
language names, so it would be possible to create a dropdown menu for the
style language with options “All languages”, “Afrikaans”, “Arabic”, etc.
You could populate the list based on the default-locale values of the
styles in the repository. There is also the distinction between styles with
and without a set default-locale (with only the latter localizing to the
client-provided locale), and we might want to label those latter styles as
“International”. If that’s all too difficult Sebastian’s three-way “no
default language”/“English”/“non-English” division would work as well.
