Simon,
I noticed this from the SVN log:
I’m confused. It seems you removed the branch locales files, which is
fine. But why does your log entry say “current versions are available in
the Zotero repository”? The “current version” should be maintained along
with the schema, since they’re tightly coupled; no?
Bruce
We can add it back, but it seems to me that it’s more trouble than
it’s worth to maintain separate versions of the files in two
repositories, since any modifications have to be merged to both. The
Zotero repository also contains locales.xml files localized in non-
English languages, which were never in the xbiblio repository.
Simon
But why are you maintaiining these files in your repo at all? They
are specific to CSL; not Zotero. As a result, you’ll force every
implementor to create and maintain their own, or go hunting in your
repo for them. Not good.
Also, Johan had a Dutch locales file in this repo.
Bruce
Obviously, Zotero uses the locales files to format CSLs, and won’t
operate without them, which is why there’s a copy in our repository.
There’s no way to avoid this. If you want to keep the canonical copies
of the locales files in the xbiblio repository, you or I can merge
changes into the Zotero repository, but the Zotero repository is no
less accessible to implementors than the xbiblio repository, and, to
me, this just seems like a waste of time.
At the moment, we have locales files in 35 different languages,
including one in Dutch, in extension/branches/1.0/chrome/content/
zotero/locale/csl.
Simon
Simon Kornblith wrote:
Obviously, Zotero uses the locales files to format CSLs, and won’t
operate without them, which is why there’s a copy in our repository.
There’s no way to avoid this.
That’s fine. What I don’t want is for you to make changes to those files
that don’t show up here. That would be not much better than if you kept
a local copy of the CSL schema and edited it. It’s effectively a fork,
for no obvious reason than a mild question of convenience.
If you want to keep the canonical copies
of the locales files in the xbiblio repository, you or I can merge
changes into the Zotero repository, but the Zotero repository is no less
accessible to implementors than the xbiblio repository, and, to me, this
just seems like a waste of time.
Come on Simon. Of course it’s a (very mild) waste of time for you. But
CSL isn’t just for you. The locales schema is part of CSL, as are the
locales files. They belong here. I don’t see that as an unreasonable
position. Do you?
Does anyone else have an opinion on this? To clarify, we’re talking
about the files that contain the language-specific term strings
(“accessed on”, “in”, “January”, etc.).
Bruce
After some delay, I’m looking to resume the Ruby implementation of CSL in
the new year. It would be handy to have all of the non-implementation
specific files in one logical repository, as much for convenient reference
as anything else.
Regards,
Liam.
Simon Kornblith wrote:
Obviously, Zotero uses the locales files to format CSLs, and won’t
operate without them, which is why there’s a copy in our repository.
There’s no way to avoid this.That’s fine. What I don’t want is for you to make changes to those
files
that don’t show up here. That would be not much better than if you
kept
a local copy of the CSL schema and edited it. It’s effectively a fork,
for no obvious reason than a mild question of convenience.
I agree. If you want to keep the canonical version, we should make
sure that any changes to the locales files get made in both
repositories. This isn’t a strange idea; Mozilla has its own SQLite
library source, most distros keep their own kernel source, etc. I just
want to make sure the files stay in sync.
If you want to keep the canonical copies
of the locales files in the xbiblio repository, you or I can merge
changes into the Zotero repository, but the Zotero repository is no
less
accessible to implementors than the xbiblio repository, and, to me,
this
just seems like a waste of time.Come on Simon. Of course it’s a (very mild) waste of time for you. But
CSL isn’t just for you. The locales schema is part of CSL, as are the
locales files. They belong here. I don’t see that as an unreasonable
position. Do you?
I don’t think it’s unreasonable. It doesn’t take much time for me to
import the locales from xbiblio into the Zotero repository, but, then
again, it takes the same amount of time for another implementor to
check out the locales from the Zotero repository and the schema from
the xbiblio repository (instead of all from one repository). It’s all
open source; it doesn’t belong to either of us. If you have a strong
preference for keeping the canonical versions in the xbiblio
repository, that’s fine with me.
Simon
Simon Kornblith wrote:
… it takes the same amount of time for another implementor to
check out the locales from the Zotero repository and the schema from
the xbiblio repository (instead of all from one repository).
Huh? But that presumes they know that you’re hosting the files, and
where they are. I don’t see how they could know that.
And it IS extra work for people like Liam to have to go and checkout the
files from your repository.
It’s all open source; it doesn’t belong to either of us.
That’s not the point; the point is what’s easiest to maintain, and for
different developers to access.
I think your argument that it’s reasonable that non-Zotero developers
(including me) should have to hunt around in a separate repository for
files which are really essential to the implementation of CSL really
makes no sense.
If you have a strong preference for keeping the canonical versions in the xbiblio
repository, that’s fine with me.
OK then 
Best for the new year all!
Bruce
Happy New Year!
Would it be possible to write some sort of svn-to-svn script that
syncs Zotero and Bruce’s locales files automatically? It’s a pain to
make changes in two places manually every time, and it seems that
most people currently working on CSL are Zotero developers (judging
from postings on this list among other things), who would work
primarily in Zotero svn.
At the moment, Zotero locales_en_US.xml is more complete than xbiblio
locales_en.xml, and of course there are many more CSL styles on the
Zotero site as well. Bruce, do you not want those in your repository?
Elena
Elena Razlogova wrote:
Happy New Year!
Would it be possible to write some sort of svn-to-svn script that
syncs Zotero and Bruce’s locales files automatically? It’s a pain to
make changes in two places manually every time, and it seems that
most people currently working on CSL are Zotero developers (judging
from postings on this list among other things), who would work
primarily in Zotero svn.At the moment, Zotero locales_en_US.xml is more complete than xbiblio
locales_en.xml, and of course there are many more CSL styles on the
Zotero site as well. Bruce, do you not want those in your repository?
I don’t really care about the styles, since they’re designed to be
distributed (since they have URI Ids). Indeed, that’s a major feature.
The only reason I did that earlier was just because nobody was actually
implementing CSL as I intended in this respect. In Zotero, for example,
the styles were actually embedded in a single SQL file, which made them
useless from the perspective of easy reuse.
Since Dan started to make the necessary changes with the Zotero styles
repository and auto-loading of styles in 1.02, however, that problem’s
solved. So it’d be silly for me to say styles ought to be hosted here. I
just ought to create a list of repositories on the main CSL page.
The issue with the locales files is CSL cannot be implemented without
them. They are designed to stay with the schema.
It doesn’t really matter to me how Simon implements the syncing; I’m
just saying up-to-date locales files need to be here along with the
schema, and that, for example, if you add a new term to the schema here,
you ought to add the localizations to the locale file here as well.
Bruce
This should no longer be an issue. SVN has a feature to check out a
directory from an external repository, which I just implemented. As
long as it doesn’t make branching and tagging too difficult, this is
pretty much the ideal solution.
Simon