# \[ xbiblio-Feature Requests-2553997 \] dates need to be localized
**URL:** https://discourse.citationstyles.org/t/xbiblio-feature-requests-2553997-dates-need-to-be-localized/536
**Category:** CSL Development
**Created:** [February 1, 2009, 12:01am UTC](https://discourse.citationstyles.org/t/xbiblio-feature-requests-2553997-dates-need-to-be-localized/536 "2009-02-01T00:01:43Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)
#### Post date: [February 1, 2009, 12:01am UTC](https://discourse.citationstyles.org/t/xbiblio-feature-requests-2553997-dates-need-to-be-localized/536/1 "2009-02-01T00:01:43Z")
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?---------- Forwarded message ----------
From: [SourceForge.net](http://SourceForge.net) [noreply@sourceforge.net](mailto:noreply@sourceforge.net)
Date: Sat, Jan 31, 2009 at 6:59 PM
Subject: [xbiblio-Feature Requests-2553997] dates need to be localized
To: [noreply@sourceforge.net](mailto:noreply@sourceforge.net)
Feature Requests item #2553997, was opened at 2009-01-31 18:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
[https://sourceforge.net/tracker/?func=detail&atid=678021&aid=2553997&group\_id=117435](https://sourceforge.net/tracker/?func=detail&atid=678021&aid=2553997&group_id=117435)
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: CSL Schema
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Bruce D’Arcus (bdarcus)
Assigned to: Nobody/Anonymous (nobody)
Summary: dates need to be localized
Initial Comment:
One (potentially big) problem is that the current schema does not
allow for localization of date formatting. we need to fix this.
* * *
You can respond by visiting:
[https://sourceforge.net/tracker/?func=detail&atid=678021&aid=2553997&group\_id=117435](https://sourceforge.net/tracker/?func=detail&atid=678021&aid=2553997&group_id=117435)
---
### Author:  [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)
#### Post date: [February 1, 2009, 7:31am UTC](https://discourse.citationstyles.org/t/xbiblio-feature-requests-2553997-dates-need-to-be-localized/536/2 "2009-02-01T07:31:40Z")
> 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.
Frank
---
### Author:  [@Bruce\_D\_Arcus1](https://discourse.citationstyles.org/u/Bruce_D_Arcus1)
#### Post date: [February 1, 2009, 3:11pm UTC](https://discourse.citationstyles.org/t/xbiblio-feature-requests-2553997-dates-need-to-be-localized/536/3 "2009-02-01T15:11:03Z")
Right. It is hard.
Just for reference, the relevant zotero forum thread is here:
[http://forums.zotero.org/discussion/4937/multilingual-styles-and-dateformat/](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:
Bruce
---
### Author:  [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)
#### Post date: [February 1, 2009, 10:31pm UTC](https://discourse.citationstyles.org/t/xbiblio-feature-requests-2553997-dates-need-to-be-localized/536/4 "2009-02-01T22:31:34Z")
> > > 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/](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.
Frank
---
### Author:  [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)
#### Post date: [February 3, 2009, 2:46am UTC](https://discourse.citationstyles.org/t/xbiblio-feature-requests-2553997-dates-need-to-be-localized/536/5 "2009-02-03T02:46:56Z")
> > > > 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/](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:
\ ...
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