Just added this ticket to add support for date localization; it’s a
dumb oversight that we probably need to fix before we call CSL 1.0.
Any suggestions?
This is hard. The localized dates delivered by the OS do not provide
the level of control needed by the styles, so manipulation of the
basic Y-M-D data in the CSL grinder itself seems to be unavoidable.
How about some sort of pluggable framework that assigns nicknames to
packages of localized date formats from a separate localization
bundle, so that these can be invoked in the main CSL file with a
one-liner? That would give you loads of flexibility. It would
simplify the style-level CSL, but it would also complicate maintenance
and distribution.
Right. It is hard.
Just for reference, the relevant zotero forum thread is here:
http://forums.zotero.org/discussion/4937/multilingual-styles-and-dateformat/
As the poster notes:
“While the localization via the Babelzilla-files in general works
quite well, one big problem seems to be the date format: If you set
“extensions.zotero.export.bibliographyLocale” to “de-DE” and then
create bibliographies in any given standard style, they always get the
date wrong – “November 18, 2002” instead of “18. November 2002”.”
So while we do have the month localization covered, the order of the
variables and the punctuation between them varies, and we not have any
of that covered. I guess what Frank is proposing is in essence to move
this into the locales support, so that in the body of the CSL you
might just do:
That’s it. I was thinking that CSL markup would be needed in the
localization layer, but for dates I guess that’s not necessary, is it.
By “pluggable”, I had the idea that different styles might use a
different format in the same language for “long” or “short”. To cover
that problem, you would want to have a default bundle (the existing
localization layer, plus date formats), with the possibility of
overriding a specific date format for a specific language through some
sort of CSL option.
If the override drew its format from an alternative (pre-packaged)
localization namespace, there would be a need to managing those
supplementary namespaces, and that had me thinking that it would
complicate distribution and maintenance. But if there is only a small
amount of variety, maybe you could handle the odd cases, by allowing
the style designer to set an explicit localization string for a given
language in a CSL header option.
Hold that last thought. Can the ordinary localization machinery
gracefully arbitrate between data with a full date, with only a month
and with a year only? If not, there may be a need to push CSL logic
into the localization layer, like I first thought.
Essentially all this would be is an include of a single tagged
environment, with a mechanism for slotting in a missing variable=
attribute on the outermost tag before processing. If that were done,
there might be a case to be made for doing the same thing with names
– and then into the bargain, I think you could eliminate the
“substitute” element.
In the localization bundle, you would have entries that look something
like this:
<?xml version="1.0" encoding="UTF-8"?>
...
These would be invoked with something like this:
...
With a list of variables (the second example), CSL would try each in
turn until it found one containing a value, or until all return
nothing. If variables fed to name were usable one time only, this
would do what substitute does, I think, while at the same time
simplifying the main body of CSL.
Frank