Dear xbibliophiles,
If I can revive a thread that predates my membership on this list:
http://sourceforge.net/mailarchive/message.php?msg_id=26738384
I’d like to drag this proposal into a sufficiently mature shape to get
it on track for CSL 1.1 or so, since it has major implications for my
own scholarly work. Frank’s summary of the needs for Asian scholarship
is just about the same as we need for Russian and Tatar scholarship as
well. In those cases, the bulk of the behavior changes is that the
terms should come from the locale that corresponds to the language of
the reference (in cases of Russian, English and occasionally in other
languages, either local (Tatar) or international (French)).
The proposal of setting default-locale and specifying locale on
tags, proposed by Frank on December 10, looks like a good
start:
...
...
My only addition to this is that I think there’s room for a global
option that would put localized terms in the language of the
reference, if the language is specified and the locale is defined.
Otherwise, there we’ll have to add a lot of locale-based logic to
cover the common case of European styles that use
reference-language-appropriate terms for several common scholarly
languages. My only concern with such a global option is that we might
want to be able to restrict it to a set of locales, defined within the
style.
Regards,
Avram
I think the main limitation of this is that it’s not possible to have
different global, citation-specific and bibliography-specific options
(because cs:style, cs:citation and cs:bibliography occur only once in a
style). Not sure how limiting this is.
Rintze
Dear xbibliophiles,
If I can revive a thread that predates my membership on this list:
Re: [xbiblio-devel] Proposal: test condition for "language" | XBib
I’d like to drag this proposal into a sufficiently mature shape to get
it on track for CSL 1.1 or so, since it has major implications for my
own scholarly work. Frank’s summary of the needs for Asian scholarship
is just about the same as we need for Russian and Tatar scholarship as
well. In those cases, the bulk of the behavior changes is that the
terms should come from the locale that corresponds to the language of
the reference (in cases of Russian, English and occasionally in other
languages, either local (Tatar) or international (French)).
The proposal of setting default-locale and specifying locale on
tags, proposed by Frank on December 10, looks like a good
start:
...
...
My only addition to this is that I think there’s room for a global
option that would put localized terms in the language of the
reference, if the language is specified and the locale is defined.
Otherwise, there we’ll have to add a lot of locale-based logic to
cover the common case of European styles that use
reference-language-appropriate terms for several common scholarly
languages. My only concern with such a global option is that we might
want to be able to restrict it to a set of locales, defined within the
style.
Actually, the implementation of this embedded in citeproc-js already
does that, for both terms and dates. The language variable is mapped
in multilingual Zotero, so you can run a style built with this syntax
out of the box (although it obviously won’t validate as CSL 1.0).
I’m busy, but a thought …
Dear xbibliophiles,
If I can revive a thread that predates my membership on this list:
Re: [xbiblio-devel] Proposal: test condition for "language" | XBib
I’d like to drag this proposal into a sufficiently mature shape to get
it on track for CSL 1.1 or so, since it has major implications for my
own scholarly work. Frank’s summary of the needs for Asian scholarship
is just about the same as we need for Russian and Tatar scholarship as
well. In those cases, the bulk of the behavior changes is that the
terms should come from the locale that corresponds to the language of
the reference (in cases of Russian, English and occasionally in other
languages, either local (Tatar) or international (French)).
The proposal of setting default-locale and specifying locale on
tags, proposed by Frank on December 10, looks like a good
start:
...
...
My only addition to this is that I think there’s room for a global
option that would put localized terms in the language of the
reference, if the language is specified and the locale is defined.
Otherwise, there we’ll have to add a lot of locale-based logic to
cover the common case of European styles that use
reference-language-appropriate terms for several common scholarly
languages. My only concern with such a global option is that we might
want to be able to restrict it to a set of locales, defined within the
style.
Given how high a premium we want to put on stability and compatibility
going forward, I think we probably need to evolve how we deal with
these sorts of enhancement requests.
Perhaps we need a few sections?
- use case (what needs to be done from a user perspective?)
- requirements (what needs to be done from a programming perspective?)
- proposed syntax changes (how, concretely, will this impact the schema?)
- proposed specification language changes (how will this impact the spec?)
- compatibility (what impact will this have on existing 1.0
implementations? etc.)
And perhaps we do this via the github issue tracker, which includes
support for markdown?
Bruce
I’m busy, but a thought …
Dear xbibliophiles,
If I can revive a thread that predates my membership on this list:
Re: [xbiblio-devel] Proposal: test condition for "language" | XBib
I’d like to drag this proposal into a sufficiently mature shape to get
it on track for CSL 1.1 or so, since it has major implications for my
own scholarly work. Frank’s summary of the needs for Asian scholarship
is just about the same as we need for Russian and Tatar scholarship as
well. In those cases, the bulk of the behavior changes is that the
terms should come from the locale that corresponds to the language of
the reference (in cases of Russian, English and occasionally in other
languages, either local (Tatar) or international (French)).
The proposal of setting default-locale and specifying locale on
tags, proposed by Frank on December 10, looks like a good
start:
...
...
My only addition to this is that I think there’s room for a global
option that would put localized terms in the language of the
reference, if the language is specified and the locale is defined.
Otherwise, there we’ll have to add a lot of locale-based logic to
cover the common case of European styles that use
reference-language-appropriate terms for several common scholarly
languages. My only concern with such a global option is that we might
want to be able to restrict it to a set of locales, defined within the
style.
Given how high a premium we want to put on stability and compatibility
going forward, I think we probably need to evolve how we deal with
these sorts of enhancement requests.
Perhaps we need a few sections?
- use case (what needs to be done from a user perspective?)
- requirements (what needs to be done from a programming perspective?)
- proposed syntax changes (how, concretely, will this impact the schema?)
- proposed specification language changes (how will this impact the spec?)
- compatibility (what impact will this have on existing 1.0
implementations? etc.)
And perhaps we do this via the github issue tracker, which includes
support for markdown?
I’m busy too. 
I don’t think the issue tracker will work for discussions like this. A
proposals “project” in github, containing versioned documents, might
be more appropriate. Something along the lines of Python PEP:
I used to work with Plone, which uses a similar proposal system that
they call PLIP. The admin document that describes how they fit in to
the overall development workflow is here:
Note this comment by Jon Stah:
“Jon: doesn’t feel like we have much formal process around PLIPs
before they are submitted with code to the framework team. I’d love
others’ opinions here.”
Frank
So before I think more on details, is the key to your suggestion the
“versioned documents” bit?
I’m busy, but a thought …
Dear xbibliophiles,
If I can revive a thread that predates my membership on this list:
Re: [xbiblio-devel] Proposal: test condition for "language" | XBib
I’d like to drag this proposal into a sufficiently mature shape to get
it on track for CSL 1.1 or so, since it has major implications for my
own scholarly work. Frank’s summary of the needs for Asian scholarship
is just about the same as we need for Russian and Tatar scholarship as
well. In those cases, the bulk of the behavior changes is that the
terms should come from the locale that corresponds to the language of
the reference (in cases of Russian, English and occasionally in other
languages, either local (Tatar) or international (French)).
The proposal of setting default-locale and specifying locale on
tags, proposed by Frank on December 10, looks like a good
start:
...
...
My only addition to this is that I think there’s room for a global
option that would put localized terms in the language of the
reference, if the language is specified and the locale is defined.
Otherwise, there we’ll have to add a lot of locale-based logic to
cover the common case of European styles that use
reference-language-appropriate terms for several common scholarly
languages. My only concern with such a global option is that we might
want to be able to restrict it to a set of locales, defined within the
style.
Given how high a premium we want to put on stability and compatibility
going forward, I think we probably need to evolve how we deal with
these sorts of enhancement requests.
Perhaps we need a few sections?
- use case (what needs to be done from a user perspective?)
- requirements (what needs to be done from a programming perspective?)
- proposed syntax changes (how, concretely, will this impact the schema?)
- proposed specification language changes (how will this impact the
spec?)
- compatibility (what impact will this have on existing 1.0
implementations? etc.)
And perhaps we do this via the github issue tracker, which includes
support for markdown?
I’m busy too.
I don’t think the issue tracker will work for discussions like this. A
proposals “project” in github, containing versioned documents, might
be more appropriate. Something along the lines of Python PEP:
PEP 0 – Index of Python Enhancement Proposals (PEPs) | peps.python.org
I used to work with Plone, which uses a similar proposal system that
they call PLIP. The admin document that describes how they fit in to
the overall development workflow is here:
coactivate.org - This website is for sale! - coactivate Resources and Information. Apr 20, 2011 5:15 PM, “Frank Bennett” <@Frank_Bennett> wrote:
On Thu, Apr 21, 2011 at 12:11 AM, Bruce D’Arcus <@Bruce_D_Arcus1> wrote:
On Wed, Apr 20, 2011 at 7:37 AM, Avram Lyon <@Avram_Lyon> wrote:
Note this comment by Jon Stah:
“Jon: doesn’t feel like we have much formal process around PLIPs
before they are submitted with code to the framework team. I’d love
others’ opinions here.”
Frank
Bruce
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation – Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and
improve
application availability and disaster protection. Learn more about
boosting
the value of server virtualization. Best Open Source Mac Front-Ends 2023
xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
xbiblio-devel List Signup and Options
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation – Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about
boosting
So before I think more on details, is the key to your suggestion the
“versioned documents” bit?
That, plus (in a single location) definite guidelines on what should
go into a proposal, and a clear statement of the workflow that leads
from proposal stage to adoption, rejection, or revision.
But we have to work with existing infrastructure to track that process
of proposal, discussion, and resolution: git repo, wiki, issue
tracker. That’s one thing.
Aside: worth noting that github wikis are themselves just git
repositories of markdown files.
The other thing is the actual form of proposals. We have previously
discussed the possibility of them being accompanied by tests.
So anyone have thoughts on how we put this all together?
One possible strawman, for example, is something like:
- setup csl “proposals” project (per Frank’s suggestion)
- use the project wiki for the actual proposal text, which maybe is
structured in such a way that upon acceptance, both spec content,
schema diffs, and test suite contribution can be extracted (??)
- proposals tracked and discussed in the issue tracker, with link to wiki page
Bruce