Here is some possible language for the specification. The @-numbers
given the likely place where the text blocks might be inserted in the
current document version:On Sat, Dec 11, 2010 at 6:53 AM, Frank Bennett <@Frank_Bennett> wrote:
On Sat, Dec 11, 2010 at 2:18 AM, Bruce D’Arcus <@Bruce_D_Arcus1> wrote:
On Fri, Dec 10, 2010 at 12:14 PM, Rintze Zelle <@Rintze_Zelle> wrote:
On Fri, Dec 10, 2010 at 12:01 PM, Bruce D’Arcus <@Bruce_D_Arcus1> wrote:
On Fri, Dec 10, 2010 at 11:54 AM, Rintze Zelle <@Rintze_Zelle> >>>> wrote:
On Fri, Dec 10, 2010 at 11:40 AM, Bruce D’Arcus <@Bruce_D_Arcus1> >>>> > wrote:
…
The bigger issue here isn’t these CSL syntax details, it’s what
implementing this would mean for the input model. Effectively, we
would need to change input JSON from:
“title”: “The Title”
… to:
“title”: { “value”: “The Title”, “lang”: “en” }
The “language” variable would be a property of the item, right, instead
of
of the individual variables? I.e.
{ “title”: “The Title”, “lang”: “en” }
instead of
{ “title”: { “value”: “The Title”, “lang”: “en” } }
The former isn’t valid.
Either the value of the key (in this case, the title) is a string (as
it is now), or it’s a hash/dictionary or list (as it would have to be
to support this proposal).
Isn’t Frank proposing to just add a “language” variable, independent of the
“title” variable? E.g.:
[
{
“id”: “ITEM-1”,
“language”: “de-DE”,
“title”: “Some title”,
“type”: “book”
}
]
I don’t know. That wasn’t the impression I got (mainly from his
response to my question about the model), but I could be wrong.
In any case, that approach would only work if you assumed all key
values were of the same language, which might not work in some cases
(like if you have a translation but also include data from the
original language; probably need to know what language that original
data is in).
Sorry for the confusion. It’s been a hectic two weeks, and I threw
the discussion off track with that ill-considered response earlier.
Stepping back …
For multilingual processing, there are two cases to consider: (a)
styles that require foreign language cites to be transliterated
(possibly with supplementary translations) and composed in the native
form of the document’s own language; and (b) styles that require
(certain) foreign language cites to be composed in their own, foreign,
native format.
An example of (a) might look like this:
[1] Maruyama, Hiro, “Koen to tochi shyou (5)" [Parks and Eminent
Domain, Part 5], Nihon zoen gakkai zasshi 50, no. 5 (March 1987):
42-47.
[2] Mauro, Paolo. “Corruption and Growth.” The Quarterly Journal of
Economics 110, no. 3 (August 1995): 681-712.
An example of (b) might look like this:
[1] 丸山宏、「公園と土地収用」、日本造園学会雑誌、1987年3月50巻5号42-47頁。
[2] Mauro, Paolo. “Corruption and Growth.” The Quarterly Journal of
Economics 110, no. 3 (August 1995): 681-712.
In (a), the locale is the same throughout (en-US), and the metadata
content is mangled into a script that is familiar to readers and plays
nice with surrounding punctuation.
In (b), the metadata content is left untouched, but the locale is
adapted to the script used in the cite.
The proposal here relates to (b). Mixed-locale styles of this kind
are the norm in countries with languages that use non-roman scripts.
The use of a conditional to set the locale seems to work out nicely,
but the details of the match condition and selection of the locale to
be applied are still in flux.
Apologies again for the confusion.
Frank
@1385
language
Tests whether the language field of the item to be
rendered matches any of the given locales. This is
treated as a single test for all values of purposes of
the match attribute (“none”, “any”, or “all”).
When the test succeeds, the locale is changed to the
tested value for all child nodes called via the test.
See The language test attribute_ below for details
on the locale selection.
@1398
The language test attribute
^^^^^^^^^^^^^^^^^^^^^^^^^^^
The language test attribute accepts a list of locale
specifiers. Specifiers may be either a two-character
language code (e.g. “en”, for English), or a two-character language code
and a two-character region code separated by a hyphen
(e.g. “de-CH”, or the variant of German spoken in Switzerland).
Testing and locale assignment are performed as follows:
-
The test succeeds if any of the given language specifiers match
against the language field of the item to be rendered;
-
Two-character language specifiers (those without a region code)
match any item language value for that language, regardless
of the region tag;
-
The first language specifier in the list determines the
locale to be set on children of the condition statement.
The following examples illustrate this behavior:
… sourcecode:: xml
<choose>
<if language="pt">
<text macro="cite"/>
</if>
<else>
<text macro="cite"/>
</else>
</choose>
In the example above, the “cite” macro will be executed with the
base locale of Portuguese (“pt-PT”) for any item with a language
field value of Portuguese (e.g. “pt”, “pt-BR”, or “pt-PT”). For
all other items, the “cite” macro will be executed with the default
locale of the style.
… sourcecode:: xml
<choose>
<if language="zh-CH">
<text macro="cite"/>
</if>
<else-if language="zh-TW">
<text macro="cite"/>
</else-if>
<else>
<text macro="cite"/>
</else>
</choose>
In the example above, the “cite” macro will be executed with
the mainland (simplified) Chinese locale for items that have the
specifier “zh-CH” set in the language field. Items
that have the specifier for the non-simplified version of
Chinese used in Taiwan set in the language field (“zh-TW”) will be
rendered with that locale. All other items will be rendered with
the default locale of the style.
… sourcecode:: xml
<choose>
<if language="de-AT de">
<text macro="cite"/>
</if>
<else>
<text macro="cite"/>
</else>
</choose>
In the example above, the “cite” macro will be executed
with the Austrian locale (“de-AT”) for all items that have
German set in the item language field, regardless of
region code.
Frank