Rintze and I have looked at the initial schema patch for localized
dates, and we’ve come up with a modified plan, which I’ve checked in
as a “localized dates remix”. This note explains the overall scheme
for handling localized dates, and the reason for the changes we made
in the remix patch.
Like the original version, the remix is backward compatible with date
nodes in existing CSL styles. Upgrade to localized dates is purely
voluntary. Most styles in the repository are specific to individual
journals, and for the system upgrade, the plan would be to leave the
date nodes in such styles untouched, on the assumption that they are
bound to a single language. Date localization would be enabled only
for the generic styles, but journals that require multi-language
support could be upgraded on an ad hoc basis. The number of such
styles is small, and if required the changes can be applied by hand.
As in the original version, localized dates are written into the
locale in much the same way as ordinary date nodes in the current
schema:
Date nodes in the locale differ from old-style date nodes in the
layout on three points: they have a form= attribute, which provides a
handle to call the localized date form defined by the node; they have
no variable= attribute; and they have no affixes on the date element.
In the remix, form= must be one of two values: “text” or “numeric”.
Each should define a full date with the three date-part names “year”,
“month” and “day”.
The remix, like the original version, allows the localized form of the
date to be called from inside layout using a bare date element with no
children:
In the original version of the patch, forms such as “year-month” and
"year" were included. We concluded that this scheme was flawed in two
ways. First, it mixed the date format (text vs numeric) with the
choice of precision (year-month). As discussed in the next paragraph,
the new scheme separates these two concepts, resulting in a design
that is both simpler and more flexible. The second flaw was in a lack
of control over the degrading of “year-month” when incomplete data is
available. If used in a style together with “year” to compose a date
(as some styles do, in practice), the localized form might be "Jan 10"
for year-month, and “2000” for year. If these are joined with a comma
in the layout, they will produce “Jan 10, 2000”. However, if the day
is missing, this would yield “Jan, 2000”, which is unlikely to be
correct.
Our solution was to declare only the full date in the locale, as shown
above, and to provide a forced degrading option, date-parts=, which
takes values of “year-month-day” (the default), “year-month”, and
"year". This optional attribute gives the style author control over
the granularity of each date used in a citation, and also permits
graceful degrading of the date form, in the event of missing data.
(Note that graceful degrading depends upon the careful assignment of
affixes to the “month” and “day” date-parts. The example localized
date given above will degrade properly.)
The only other change in the remix is to allow strip-periods on
localized date elements in the layout. This was added because the
"month" date-part is not directly accessible in the layout for a
localized date; with the remix patch, if strip-periods is set, the
option will be inherited by the “month” date-part in the localized
date, so that both with-period and without-period date forms can be
supported by the same locale date declaration.
That’s the plan, anyway. The schema changes for the remix patch have
been checked in to xbiblio svn, and a test suite has been prepared,
which currently passes in citeproc-js.
http://bitbucket.org/fbennett/citeproc-js/src/tip/std/humans/
(see the date_Localized* tests)
We’re happy that this is likely to serve the needs of the generic
styles — except for IEEE. That style requires different date forms
for different categories of source. It seems unlikely to be imposed
across languages, however, so we’re inclined to treat it as a
journal-specific style, without dates localization.
How does it look?
Frank