Bringing back up language

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:
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.

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:
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.

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:
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.

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. :slight_smile:

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:

http://www.coactivate.org/projects/plone-strategic-planning/plone-community-processes

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:
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.

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. :slight_smile:

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:

http://www.python.org/dev/peps/

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:

http://www.coactivate.org/projects/plone-strategic-planning/plone-community-processesOn 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. http://p.sf.net/sfu/vmware-sfdev2dev


xbiblio-devel mailing list
xbiblio-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel


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