Can people please take a look at these changes (am tired am may well
have made some dumb mistake!)?------------------------------------------------------------------------
r1066 | bdarcus | 2009-07-12 17:05:52 -0400 (Sun, 12 Jul 2009) | 1 line
Full Date Format in Native Language: tisdag 10 april 1998
Long Date Format in Native Language: 10 april 1998
Common Date Format in Native Language: 1998-04-10
Short Date Format in Native Language: 98-04-10
In locales-sv-SE.xml:
Måndag
Tisdag
Onsdag
Torsdag
Fredag
Lördag
Söndag
Styles could then just call a standard date-format (e.g. just ), and override date formats via the locales-element in
the style. I can even imagine that one could use to just show year-month (e.g. 1998-04); the parts
attribute would provide an unordered subset of date-parts to render.
Small elaborations on my suggestion: I really would like a way to
define delimiters between date-parts (IMHO it’s the only way
incomplete dates, e.g. dates lacking day numbers, can be correctly
rendered). Furthermore, I understand that showing the week-day will
require some logic to calculate the weekday matching a certain date.
Don’t know if that’s worth the trouble. Finally, I’ll admit it’s all
terribly backwards-incompatible, but I don’t see how we can come to
full fledged date support otherwise.
Frank suggested we could still allow date formats to be overruled by
the existing way to specify date formats: “A date singleton would call
on the locale def, but you could allow a full date span, which would
just do its own thing, the way things work now”. Although styles doing
that wouldn’t benefit from date-localization, it seems to be backwards
compatible.
Well, it’s certainly my intention to allow this. I was just tired of
talking about it, and thought we ought to start implementing.
Full Date Format in Native Language: tisdag 10 april 1998
Long Date Format in Native Language: 10 april 1998
Common Date Format in Native Language: 1998-04-10
Short Date Format in Native Language: 98-04-10
In locales-sv-SE.xml:
Måndag
Tisdag
Onsdag
Torsdag
Fredag
Lördag
Söndag
Styles could then just call a standard date-format (e.g. just ), and override date formats via the locales-element in
the style. I can even imagine that one could use to just show year-month (e.g. 1998-04); the parts
attribute would provide an unordered subset of date-parts to render.
Small elaborations on my suggestion: I really would like a way to
define delimiters between date-parts (IMHO it’s the only way
incomplete dates, e.g. dates lacking day numbers, can be correctly
rendered).
I’ll look at this later.
Furthermore, I understand that showing the week-day will
require some logic to calculate the weekday matching a certain date.
Don’t know if that’s worth the trouble.
It’s not
Finally, I’ll admit it’s all terribly backwards-incompatible, but I don’t see how we can come to
full fledged date support otherwise.
Right; this was a stupid design decision in CSL, and I see no way to
reasonably fix it without breaking things.
Second, my main goal in this set of changes was to align date and name
formatting and localization. I don’t mind if we have to break things
to get this, because it’s pretty critical.
Finally, I’ll admit it’s all
terribly backwards-incompatible, but I don’t see how we can come to
full fledged date support otherwise.
Frank suggested we could still allow date formats to be overruled by
the existing way to specify date formats: “A date singleton would call
on the locale def, but you could allow a full date span, which would
just do its own thing, the way things work now”. Although styles doing
that wouldn’t benefit from date-localization, it seems to be backwards
compatible.
First, I don’t know what a singleton is.
Second, my main goal in this set of changes was to align date and name
formatting and localization. I don’t mind if we have to break things
to get this, because it’s pretty critical.
I’m kind of confused. What would it mean to align formatting and
localization for dates and names?
Second, my main goal in this set of changes was to align date and name
formatting and localization. I don’t mind if we have to break things
to get this, because it’s pretty critical.
I’m kind of confused. What would it mean to align formatting and
localization for dates and names?
Am talking more meta than that; that formatting of the parts are
independent of ordering of the parts, which is in turn
locale-specific.
The problem of the current date handling is that it collapses
formatting and ordering, and so breaks the goals of styles being
locale-independent.
Add another option: maybe “date-full-order” (“year-first” and “year-last”)?
I’d expected something more extensive and flexible,
e.g. (using the Swedish example):
Full Date Format in Native Language: tisdag 10 april 1998
Long Date Format in Native Language: 10 april 1998
Common Date Format in Native Language: 1998-04-10
Short Date Format in Native Language: 98-04-10
Do we have any evidence all of this is needed?
In locales-sv-SE.xml:
Måndag
Tisdag
Onsdag
Torsdag
Fredag
Lördag
Söndag
As I suggested; this is serious overkill.
Styles could then just call a standard date-format (e.g. just ), and override date formats via the locales-element in
the style. I can even imagine that one could use to just show year-month (e.g. 1998-04); the parts
attribute would provide an unordered subset of date-parts to render.
Small elaborations on my suggestion: I really would like a way to
define delimiters between date-parts (IMHO it’s the only way
incomplete dates, e.g. dates lacking day numbers, can be correctly
rendered).
All that’s needed for quote localization is to set those four items
(open-quote, close-quote, open-single-quote, close-single-quote) as
ordinary terms. No need to cast them as options.
All that’s needed for quote localization is to set those four items
(open-quote, close-quote, open-single-quote, close-single-quote) as
ordinary terms. No need to cast them as options.
Yeah, that’s what I meant to do. As I said; was tired.
OK; fixed. However, I did keep the punctuation config as an option.
Germany:
d.m.(yy)yy or d. month (yy)yy (periods/spaces as delimiters, no leading zeros)
France:
dd/mm/yyyy (delimiters, leading zeros)
Rintze raises an important point. The justification for filling out
localization with dates support is to allow one unifom style to
support multiple languages. A few non-English styles have already
appeared in the repository, and the test for an extended localization
scheme would be whether it would allow them to be merged back into the
core styles from which they are derived. Otherwise there doesn’t seem
to be any gain from the extral work involved.
One example would be chicago-author-date.csl and
chicago-author-date_de.csl (zotero.org not available as I write this,
so can’t offer a link). As Rintze’s list above suggests, the German
version of Chicago Author-Date uses different punctuation from
English. It seems like the obvious way to give the locale that level
of control over date formatting is to move the date/date code blocks
currently located in the style body into the locale, and then call the
locale-defined date configurations from the style body with a
“singleton” like .
