# proposal: splitting off terms from core language \[was Status page for style repository\]

**URL:** <https://discourse.citationstyles.org/t/proposal-splitting-off-terms-from-core-language-was-status-page-for-style-repository/1116>\
**Category:** CSL Development\
**Created:** [August 12, 2012, 10:25pm UTC](https://discourse.citationstyles.org/t/proposal-splitting-off-terms-from-core-language-was-status-page-for-style-repository/1116 "2012-08-12T22:25:11Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [August 12, 2012, 10:25pm UTC](https://discourse.citationstyles.org/t/proposal-splitting-off-terms-from-core-language-was-status-page-for-style-repository/1116/1 "2012-08-12T22:25:11Z")

</div>

> I have a hard time seeing any advantages of such an approach, but please  
> prove me wrong.
> 
> When we introduce new terms, style authors should be confident that those  
> terms have translations in the locale files, and, AFAIK, none of the CSL  
> apps support automatic style updating, let alone locale updating.

Well, that’s their problem; how hard can it be?

Mendeley guys? Zotero guys? Anyone else?

> Just dismissing that as being the problems of the implementations doesn’t seem  
> like a workable short-term solution.

I guess I’ll go back to my earlier question in reply:

How does having style branches (as well as updated schema and  
specification releases) for every trivial (x.x.x) change help anyone?

What work will implementers (or even worse, users) have to do just to  
accommodate this approach, and how would that work compare to what I’m  
suggesting here (my guess is my suggestion is easier to implement)?

I think we’re overloading the notion of a CSL version change to cover  
too many issues.

Bruce

---

<div class="post-metadata">

**Author:** ![Frank\_Bennett](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/frank_bennett/32/198_2.png) [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)\
**Post date:** [August 13, 2012, 12:16am UTC](https://discourse.citationstyles.org/t/proposal-splitting-off-terms-from-core-language-was-status-page-for-style-repository/1116/2 "2012-08-13T00:16:52Z")

</div>

> > I have a hard time seeing any advantages of such an approach, but please  
> > prove me wrong.
> > 
> > When we introduce new terms, style authors should be confident that those  
> > terms have translations in the locale files, and, AFAIK, none of the CSL  
> > apps support automatic style updating, let alone locale updating.
> 
> Well, that’s their problem; how hard can it be?
> 
> Mendeley guys? Zotero guys? Anyone else?

Bruce: I’m not quite sure what you’re suggesting. Is the idea that  
there would be one master styles repo, with the most recent release  
version of each style, to be run with processors that groke the most  
recent schema and locale releases? Or are you suggesting that style  
version branches should only be cast at larger (schema) version  
increments?

With respect to locale files, is the idea that a given schema version  
should not have a declared dependency relation to a given locale  
release? I don’t see how you could avoid that and still keep things  
working, but I may be missing your point.

Frank

---

<div class="post-metadata">

**Author:** ![Charles\_Parnot](https://avatars.discourse-cdn.com/v4/letter/c/57b2e6/32.png) [@Charles\_Parnot](https://discourse.citationstyles.org/u/Charles_Parnot)\
**Post date:** [August 13, 2012, 5:09am UTC](https://discourse.citationstyles.org/t/proposal-splitting-off-terms-from-core-language-was-status-page-for-style-repository/1116/3 "2012-08-13T05:09:41Z")

</div>

My 2 cents on those different subjects, mostly from the perpspective of Papers:

- I like the idea of having a ‘legacy’ branch for styles compatible with the previous version of CSL, just to ease the transition; I don’t think those branches should be maintained for very long (maybe a few weeks), but these would provide a way to fix any important issue with a specific style for clients that are still a version behind (for instance, we may decide to keep CSL 1.0 for a minor version release, and would like to make sure our styles are all good); for the sake of testing how this would work for future transitions, maybe it could be worth giving it a try with the 1.0 to 1.0.1 transition;

- I would tend to agree with Bruce that we don’t need to tie the terms to a specific version of CSL; we update the locales at every update, and if a user wants to develop a new style with a just added term, well, they’ll just have to wait a bit before it works in Papers; I think the gained flexibility is well worth the annoyance of getting client up to speed; locales would also probably the easiest ones to grab from the repository in a more automated fashion by the app

So I believe I agree with Rintze on the first point, and agree with Bruce on the second 🙂

charles

---

<div class="post-metadata">

**Author:** ![Rintze\_Zelle](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/rintze_zelle/32/175_2.png) [@Rintze\_Zelle](https://discourse.citationstyles.org/u/Rintze_Zelle)\
**Post date:** [August 13, 2012, 7:24am UTC](https://discourse.citationstyles.org/t/proposal-splitting-off-terms-from-core-language-was-status-page-for-style-repository/1116/4 "2012-08-13T07:24:35Z")

</div>

There are very few cases where new terms are introduced by themselves,  
though. In most cases they are accompanied by new variables, or new logic  
in the CSL processor. If the goal is to make CSL development more agile,  
then there are other ways to do that.

Also, it’s clear that most changes to CSL don’t receive very close scrutiny  
from all parties involved at the time they are developed (which I can  
understand, as following everything takes quite a bit of time). But because  
of that, capturing all changes to CSL into versioned releases, and creating  
review periods (like the one we’re in right now for 1.0.1) gives me some  
peace of mind, as it provides short time frames where I ask people for  
their attention.

RintzeOn Mon, Aug 13, 2012 at 1:09 AM, Charles Parnot \<@Charles\_Parnot\>wrote:

---

<div class="post-metadata">

**Author:** ![Bruce\_D\_Arcus1](https://avatars.discourse-cdn.com/v4/letter/b/4bbf92/32.png) [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)\
**Post date:** [August 13, 2012, 11:19am UTC](https://discourse.citationstyles.org/t/proposal-splitting-off-terms-from-core-language-was-status-page-for-style-repository/1116/5 "2012-08-13T11:19:36Z")

</div>

> > > I have a hard time seeing any advantages of such an approach, but please  
> > > prove me wrong.
> > > 
> > > When we introduce new terms, style authors should be confident that those  
> > > terms have translations in the locale files, and, AFAIK, none of the CSL  
> > > apps support automatic style updating, let alone locale updating.
> > 
> > Well, that’s their problem; how hard can it be?
> > 
> > Mendeley guys? Zotero guys? Anyone else?
> 
> Bruce: I’m not quite sure what you’re suggesting. Is the idea that  
> there would be one master styles repo, with the most recent release  
> version of each style, to be run with processors that groke the most  
> recent schema and locale releases? Or are you suggesting that style  
> version branches should only be cast at larger (schema) version  
> increments?

The latter.

> With respect to locale files, is the idea that a given schema version  
> should not have a declared dependency relation to a given locale  
> release? I don’t see how you could avoid that and still keep things  
> working, but I may be missing your point.

I’m not sure of the precise details yet, except to say that we  
decouple locales from core schema. It could be that locates get a  
separate versioning scheme (maybe by date?).

Bruce

---

<div class="post-metadata">

**Author:** ![Frank\_Bennett](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/frank_bennett/32/198_2.png) [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)\
**Post date:** [August 13, 2012, 12:52pm UTC](https://discourse.citationstyles.org/t/proposal-splitting-off-terms-from-core-language-was-status-page-for-style-repository/1116/6 "2012-08-13T12:52:20Z")

</div>

> > > > I have a hard time seeing any advantages of such an approach, but please  
> > > > prove me wrong.
> > > > 
> > > > When we introduce new terms, style authors should be confident that those  
> > > > terms have translations in the locale files, and, AFAIK, none of the CSL  
> > > > apps support automatic style updating, let alone locale updating.
> > > 
> > > Well, that’s their problem; how hard can it be?
> > > 
> > > Mendeley guys? Zotero guys? Anyone else?
> > 
> > Bruce: I’m not quite sure what you’re suggesting. Is the idea that  
> > there would be one master styles repo, with the most recent release  
> > version of each style, to be run with processors that groke the most  
> > recent schema and locale releases? Or are you suggesting that style  
> > version branches should only be cast at larger (schema) version  
> > increments?
> 
> The latter.

Some of the changes in processor logic this time around are pretty  
significant, and tightly tied to specific changes in the locale. What  
determines the size of the increment in this case? Is the issue the  
number assigned to the release, or the degree of change in CSL?

> > With respect to locale files, is the idea that a given schema version  
> > should not have a declared dependency relation to a given locale  
> > release? I don’t see how you could avoid that and still keep things  
> > working, but I may be missing your point.
> 
> I’m not sure of the precise details yet, except to say that we  
> decouple locales from core schema. It could be that locates get a  
> separate versioning scheme (maybe by date?).

So long as we have specific guidance on version dependencies for the  
release, the numbering scheme could be anything, I guess. It would be  
easier to follow if the branch numbers under schema, locales and  
styles were aligned, though.