Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

proposal: allow locale-specific layouts #63

Open
fbennett opened this Issue · 8 comments

3 participants

@fbennett

In non-English publishing, foreign references are often provided in the native script, and follow the formatting conventions of the language realm from which they originate. To correctly handle such styles, it is sufficient to switch to the target locale when rendering references from the target language. The "language" variable on individual items can be used for this purpose, together with locale-specific layouts set with the following syntax:

<citation>
  <layout locale="en es">
    ...
  </layout>
  <layout>
    ...
  </layout>
</citation>

With a default locale of "ru", this would format items with no value or "ru" in the "language" field using the code for the default layout in the "ru" locale, while items with "en" in the "language" field would be formatted using code for the "en es" layout in the corresponding "en" locale.

@fbennett

A patch covering this proposal is available for preview here [link updated].

@avram

while items with "en" in the "language" field would be formatted using code for the "en" layout in the corresponding "en" locale

Should that be 'with "en" or "es"'? And at this point do we point to BCP 47 and say that BCP 47 language tags are what we're talking about?

@fbennett

The full spec description will need to refer to BCP 47, for sure. In the example, that should read `formatted using the code for the "en es" layout in the corresponding "en" locale', to be more precise. But it's right that the "en" locale would be applied.

@fbennett

For this item, I'll treat the first entry as a document, and make revisions to the proposal in response to comments and discussion.

@rmzelle
Owner

See also http://xbiblio-devel.2463403.n2.nabble.com/Proposal-test-condition-for-quot-language-quot-td5775633.html

As I mentioned to Frank off-list, this solution has a few constraints, in that attributes that are specific to cs:style, cs:citation and cs:bibliography cannot have separate values for the separate locales (initialize-with-hyphen, demote-non-dropping-particle, page-range-format, the disambiguation and collapsing options (on cs:citation), near-note-distance, subsequent-author-substitute and some white-space options for cs:bibliography). That might not be a deal-breaker, though.

@fbennett

As I mentioned to Frank off-list, this solution has a few constraints, in that attributes that are specific to cs:style, cs:citation and cs:bibliography cannot have separate values for the separate locales (initialize-with-hyphen, demote-non-dropping-particle, page-range-format, the disambiguation and collapsing options (on cs:citation), near-note-distance, subsequent-author-substitute and some white-space options for cs:bibliography)

Those limitations shouldn't be a problem. If there is demand for any of those options, they can be allowed on the non-default cs:layout elements together with the locale.

@avram

So we're saying that if locale is specified at all in cs:layout, then language-specific term usage will be automatically activated? And otherwise a single locale's terms will be applied, which is the current behavior.

And just to be 100% clear, you mean:
[..] while items with "en" in the "language" field would be formatted using code for the "en es" layout using terms from the corresponding "en" locale, and items with "es" in the "language" field would be formatted using code for the "en es" layout, using terms from the corresponding "en" locale.

Correct? That is, the locale attribute specifies a list of affected language (tags)?

Once we start using tags like this, we also run into tag matching issues-- do we allow subtags to be used? Probably. How do we handle matching for them? That is, if I've specified:

<citation>
  <layout locale="ja-alalc97 en">
    ...
  </layout>
  <layout locale="ja">
    ...
  </layout>
  <layout>
    ...
  </layout>
</citation>

(which is reasonable, since the ALA-LC romanized version probably uses English-style conventions)

.. then is that legal? What if we have only partial matches between the language tags in the incoming data (say, zh) and the specified layouts (say, zh-TW, zh-CN)? I'm eager to start exploring and working this out, but as we know well, language tags are a messy world.

@fbennett

No, that wouldn't work in the current implementation, but I'm pretty sure you wouldn't set things up that way in any case.

The value of locale is a CSL locale, possibly with a region modifier. So zh, zh-TW, zh-CN, de, de-DE and de-AT would all be valid. The BCP 47 tag ja-alalc97 would not (well, it would validate with the proposed patch, but the processor would ignore everything but the "ja"). So when I agreed we are looking at BCP 47 tag values, I misspoke.

Where a style wants things romanized, it should do so everywhere. If the terms of the primary language of the document (English, say) are to be adopted, then in MLZ you would request romanization in the document, and that's all there is to it. If the terms used in foreign language cites are to be those of the item language, then you could set an alternative layout locale with this syntax, and provide romanized versions of the terms (if appropriate) in the style itself. So long as they are applied uniformly for all items in that language within the style (which they certainly should be), there shouldn't be a problem.

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.