Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

proposal: add "language" as a CSL variable #55

Open
fbennett opened this Issue · 18 comments

5 participants

@fbennett

This item relates to a recent Zotero ticket, opened in response to an issue raised on the forums.

The immediate issue is that title case conversion (text-case="title") is not appropriate in many languages. From initial feedback, it appears to be used only in English; when items are cited in other languages, the transformation should be suppressed.

It would be good to describe the behavior in the specification, and including "language" in the list of CSL input variables would open a path to that. The details of how the value is handled by processors -- how it is to be structured or parsed, and the conditions under which text-case="title" should be suppressed or invoked -- should be discussed as well, but getting the variable in place will be a first step.

@rmzelle
Owner

Can we use xsd:language for the attribute value? (the same we currently use for default-locale and xml:lang)

@fbennett

There have been discussions about that among multilingual users. The consensus seems to be that leaving the field as free text is preferable, since many people have used this as a loose descriptive field (in Zotero). It can be handled in a way similar to cs:number, recognizing a language tag if it occurs at the beginning of the field content.

@rmzelle
Owner

Well, it doesn't matter for the schema, because we don't validate against variable content.

@bdarcus
Owner

I'm not following this thread. Can you give examples of how this would impact CSL; the schema and/or an example style fragment?

@rmzelle
Owner

If I understand Frank correctly, the primary request is to add a "language" variable to CSL, which can then be populated with the existing "language" field in the Zotero data model. That would already allow for testing variable content, e.g. <if variable="language"/> (plus some automatic citeproc-js trickery), but we can work out more comprehensive support for per-item rendering based on language later by extending CSL.

@fbennett

It's about the specification more than the schema -- perhaps the variable doesn't need to be in the schema itself.

The problem is that "title case" is a feature specific to English orthography. So a style mainly aimed at an English-speaking audience may have something like this:

<text variable="title" text-case="title"/>

An English title would be set in title case: "Reflections on a Damaged Life".

A German title, however, should not be touched: "Reflexionen aus dem beschädigten Leben".

The only reliable way to determine the language of the cite is by supplying a language tag to the processor. The aim of this ticket is just to open a path to describing this behavior in the specification.

@bdarcus
Owner

OK, here's the requirement I was just asking for on the forums:

The only reliable way to determine the language of the cite is by supplying a language tag to the processor.

Can you tighten this up? "A language tag" for what? The style? The item record? The individual text variables within the item record?

@fbennett

"language tag" would be the primary language subtag of a BCF 47 (RFC 5646) language tag, indicating the default language within an item record.

@bdarcus
Owner
@fbennett

As far as we have been able to determine, yes.

(Edit: Sorry, I misread -- output target language. Yes. A German work cited with the German title in the context of an English-language publication should not be transformed to title case.)

@bdarcus
Owner

As far as we have been able to determine, yes.
Just wondering if the two might interact somehow. In either case, if I
understand you right, this requires:

  1. a new "language" key on the json schema for the input format.
  2. a sentence or two in the specification

Is that right?

If yes, I'm not understanding the schema CSL connection, unless you're saying that users would be forced to configure language-based handling explicitly in styles. The only way to do that would be not just to test for the presence of the variable, but its contents, which we have yet to allow in CSL. E.g.:

<if language="de">...</if>

Right?

@fbennett

Yes for (1) and (2), and you're right that there is no schema CSL connection. There would be no change to existing CSL style code.

@avram

If yes, I'm not understanding the schema CSL connection, unless you're saying that users would be forced to configure language-based handling explicitly in styles.

We don't anticipate that being needed. It will be necessary to sometimes use the corresponding locale for citation, or to sort by language, but we don't yet have any cases of needing explicit testing for individual languages.

Edit: And application of language-specific locale rules for each citation is something that will have to be covered by a future revision of the spec, of course, once we figure out what the range of possibilities is.

@jbis

Hi everyone,

variable language would be great for every comparative work for exemple. I´m writing a thesis in french german comparative law and have to citate both french and german sources, in each respective style of citation.

I use until now instead of language, which work very well, but is not very academic ;) especially if there is already language field in zotero...

well thank you for your great work

@jbis

(sorry code disappeared) i use the variable "note", which i don´t need.

@rmzelle
Owner

I noticed that while the Zotero language field is now exposed to citeproc-js (https://www.zotero.org/trac/ticket/1834), we don't have a CSL variable or field yet. For now, should I just add a "language" field to https://github.com/citation-style-language/schema/blob/master/csl-data.json, at the level of all the other CSL variables?

@fbennett

I think we shouldn't need direct access to the variable in CSL. In the current proposal, the value is accessed by the processor only when cs:layout carries a locale attribute. It is not available in conditions. It's set up that way because a change in locale might cause a change in delimiter punctuation, so the locale change needs to capture the entire cite for things to render correctly.

So no change needed, I think.

@rmzelle
Owner

I added the "language" field to csl-data.json: 124eaff

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.