I created 1.0 branches for the styles and locales repositories ( https://github.com/citation-style-language/locales/tree/1.0 and https://github.com/citation-style-language/styles/tree/1.0 ). Anyone who
wants to avoid CSL 1.0.1 styles and locale files for now can use those
branches, or just stop pulling updates from Github. Further development and
maintenance will occur in the “master” branches. The master branch of the
locales repository already contains CSL 1.0.1 locale files, and from today
onwards we will accept CSL 1.0.1 styles in the master branch of the styles
repository. All the CSL 1.0 styles currently in the repository validate
against the CSL 1.0.1 schema.
CSL 1.0.1 styles require CSL 1.0.1 locale files to function optimally, so
please start shipping CSL 1.0.1 locale files to your users when possible
(CSL 1.0 locales don’t cover new terms, such as “available at”, and use a
now out-dated scheme to define ordinal suffixes (see http://citationstyles.org/downloads/release-notes-csl101.html#localization-of-ordinals)).
citeproc-js should already support most, if not all, CSL 1.0.1 features.
There is still some documentation that has to be updated (e.g. on citationstyles.org, the Zotero wiki, and the CSL GitHub wikis), and I hope
to update some of that in the next few days. Let me know if I missed
anything.
Frank just reminded me that citeproc-js does not yet support the new scheme
for ordinal suffixes, so Zotero/Mendeley/etc. should probably wait with
distributing CSL 1.0.1 locales until that situation changes.
Congratulations and thanks for the great work you put into this release, Rintze!
I’ll look into updating the test suite to use the new schema for 1.0.1 styles. Incidentally, if I remember correctly, you mentioned that styles will keep using ‘1.0’ as their version string – if that’s the case, is there any straightforward way for processors to distinguish between 1.0 and 1.0.1 styles? I realize that this should not be necessary in practice, since a 1.0.1 processor will work just fine with 1.0 styles, but for validation purposes it may be useful to tell the difference; or would you prefer to validate all styles using the 1.0.1 schema?
Thanks very much for the detailed release notes, Rintze. This should be very useful in adapting our engine as well.
I am still way behind on my email and other ‘todos’. I just moved from California to France and took a week off in the middle. With the kids going back to school today, and a half-empty house, I’ll be struggling for a while!
I’ll look into updating the test suite to use the new schema for 1.0.1
styles. Incidentally, if I remember correctly, you mentioned that styles
will keep using ‘1.0’ as their version string – if that’s the case, is
there any straightforward way for processors to distinguish between 1.0 and
1.0.1 styles?
No.
would you prefer to validate all styles using the 1.0.1 schema?
Yes. All current styles in the repo validate against both the CSL 1.0 and
1.0.1 schema, but that will of course change once we start committing CSL
1.0.1-only features.
I’ll look into updating the test suite to use the new schema for 1.0.1
styles. Incidentally, if I remember correctly, you mentioned that styles
will keep using ‘1.0’ as their version string – if that’s the case, is there
any straightforward way for processors to distinguish between 1.0 and 1.0.1
styles?
Sigh … disregard previous. What I meant to say is …
I’ll look into updating the test suite to use the new schema for 1.0.1
styles. Incidentally, if I remember correctly, you mentioned that styles
will keep using ‘1.0’ as their version string – if that’s the case, is there
any straightforward way for processors to distinguish between 1.0 and 1.0.1
styles?
No.
I still think this issue of versioning and validation is a problem.
Feel free to open a ticket to express your thoughts. I generally agree that
it would be good to have some more discussion about this, but I didn’t want
to delay this release any further.
Frank just reminded me that citeproc-js does not yet support the new scheme
for ordinal suffixes, so Zotero/Mendeley/etc. should probably wait with
distributing CSL 1.0.1 locales until that situation changes.
Rintze
I finally got on the stick and implemented CSL 1.0.1 ordinals in citeproc-js.
If anyone wants to check out the new ordinals behaviour in a word
processing environment before the new locales appear in Zotero and
elsewhere, I have installed the CSL 1.0.1 locales and updated
citeproc-js version in MLZ:
I have updated csl-ruby to use the 1.0.1 schema for validation and also updated the test environment in the master branch of the styles repository. All tests pass on my computer and travis. Everyone using the test suite, please pull from the master branch and run
$ [sudo] bundle install
again to fetch the latest version and make sure the 1.0.1 schema is used for testing. If there are any problems, please let me know, I’ll be glad to help.
Also, Rintze and I are currently working on adding tests and validation to the locale repository as well – the tests are already in the locale repository but need a little more work.
Frank, I tried the latest mlz release with a style which re-defines ordinals, gender, etc.
This doesn’t work.
-limit-day-ordinals-to-day-1=“true” has no effect.
-when gender variants are defined in the ordinal suffix terms , there is no output at all with terms other than months (e.g. “edition”)
[ʳᵉ
ᵉʳ]
Frank, I tried the latest mlz release with a style which re-defines
ordinals, gender, etc.
This doesn’t work.
-limit-day-ordinals-to-day-1=“true” has no effect.
I haven’t implemented that one yet, so no worries there.
-when gender variants are defined in the ordinal suffix terms , there is no
output at all with terms other than months (e.g. “edition”)
[ʳᵉ
ᵉʳ]
That’s not good. Thanks for the report, I’ll take a look.
Frank, I tried the latest mlz release with a style which re-defines
ordinals, gender, etc.
This doesn’t work.
-limit-day-ordinals-to-day-1=“true” has no effect.
I haven’t implemented that one yet, so no worries there.
-when gender variants are defined in the ordinal suffix terms , there is no
output at all with terms other than months (e.g. “edition”)
[ʳᵉ
ᵉʳ]
That’s not good. Thanks for the report, I’ll take a look.
Is that the entire set of ordinals that are redefined in the style?
You need to provide the full set, and I think that a default term
(without gender-form) for each needs to be set. The ordinals travel
only as a full set.
I was wondering, too. Gracile explained that there is no genderless term in this case and Rintze suggested to generally fallback to the feminine version when looking up terms since that is the more common case in the languages we looked at.
Note: I haven’t worked out a general algorithm for gender lookups yet that considers all these fallbacks.
Frank, I tried the latest mlz release with a style which re-defines
ordinals, gender, etc.
This doesn’t work.
-limit-day-ordinals-to-day-1=“true” has no effect.
I haven’t implemented that one yet, so no worries there.
-when gender variants are defined in the ordinal suffix terms , there
is no
output at all with terms other than months (e.g. “edition”)
[ʳᵉ
ᵉʳ]
That’s not good. Thanks for the report, I’ll take a look.
Is that the entire set of ordinals that are redefined in the style?
You need to provide the full set, and I think that a default term
(without gender-form) for each needs to be set. The ordinals travel
only as a full set.
Is that really necessary? The example I wrote up for the specification
doesn’t define a genderless “ordinal-01” term.
Rintze
It may not be necessary in logical terms (and shouldn’t be, since
French doesn’t have a neuter gender). I’m just trying to get a fix on
the cause of the failure reported by Gracile.
Gracile: can you send me a copy of the style you used for the test?
Frank, I tried the latest mlz release with a style which re-defines
ordinals, gender, etc.
This doesn’t work.
-limit-day-ordinals-to-day-1=“true” has no effect.
I haven’t implemented that one yet, so no worries there.
-when gender variants are defined in the ordinal suffix terms , there is no
output at all with terms other than months (e.g. “edition”)
[??
??]
That’s not good. Thanks for the report, I’ll take a look.
Is that the entire set of ordinals that are redefined in the style?
You need to provide the full set, and I think that a default term
(without gender-form) for each needs to be set. The ordinals travel
only as a full set.
Frank, I tried the latest mlz release with a style which re-defines
ordinals, gender, etc.
This doesn’t work.
-limit-day-ordinals-to-day-1=“true” has no effect.
I haven’t implemented that one yet, so no worries there.
-when gender variants are defined in the ordinal suffix terms , there is no
output at all with terms other than months (e.g. “edition”)
[ʳᵉ
ᵉʳ]
That’s not good. Thanks for the report, I’ll take a look.
Is that the entire set of ordinals that are redefined in the style?
You need to provide the full set, and I think that a default term
(without gender-form) for each needs to be set. The ordinals travel
only as a full set.
Is that really necessary? The example I wrote up for the specification doesn’t define a genderless “ordinal-01” term.
I was wondering, too. Gracile explained that there is no genderless term in this case and Rintze suggested to generally fallback to the feminine version when looking up terms since that is the more common case in the languages we looked at.
Let me think out loud here for a few lines.
(1) If a masc, fem or neut variable term is called, the
corresponding genderized term should be used. That much is common
sense.
(2) If a neuter term is defined, and a masc or fem variable term is
called, and no corresponding genderized term is defined, it defaults
to the neuter term version. That’s clear from the spec.
(3) If a fem term is defined, and no neut term is defined, the fem
term becomes the default, and will be used if a masc term variant is
undefined (following the suggestion above).
(4) If only a masc term is defined, I guess that becomes the
default, and will be used if (as would logically be so) a fem term is
undefined.
I’ll confess that this will require a rewrite the locale and term
calling code in citeproc-js. I’ll wind out the latest citeproc-js
release from MLZ, and post a note when the work has been done. It will
probably be another month or so.