aligning dates and names

CSL Development
1

So I recently raised the issue that we allow formatting of individual
name parts. I heard no disagreement.

We also discussed an even bigger issue: the fact that dates are not
localized. We need to fix this.

As I’m looking at the two problems, I wonder if we ought to adopt a
common solution?

Here’s current dates:

Here’s current names:

What we decided on the latter is to allow optional child elements
which are not ordered; e.g. they only configure the formatting. The
ordering for display, then, is configured by the name-as-sort-order
attribute.

So what I’m thinking is:

  1. we add this to cs:name:

name-part = element cs:name-part { attribute name { “family” | “given” } }

  1. we change the expectations of cs:date so that children are unordered.

  2. we add an attribute to cs:name that will allow for proper localized
    formatting. I’m still a bit stuck on how best to do this, but I’m
    going to suggest adding ‘form’ so that one could do this:

In English, then, this would be rendered as …

Mar 3 1999

… with “Mar” in italics.

The problem is, in English we’d typically set-off the separate
month-day from year with a ", “. I’d expect in other renderings, like
"3 Mar 1999” that comma might not be there.

So:

  1. what do people understand about this particular issue?

  2. where should this be configured for maximum flexibility and
    localized correctness? Do we put it, for example, in the locales file
    as some attribute, and maybe allow it to be suppressed in the style?

Bruce

2

So I recently raised the issue that we allow formatting of individual
name parts. I heard no disagreement.

We also discussed an even bigger issue: the fact that dates are not
localized. We need to fix this.

As I’m looking at the two problems, I wonder if we ought to adopt a
common solution?

Here’s current dates:

Here’s current names:

What we decided on the latter is to allow optional child elements
which are not ordered; e.g. they only configure the formatting. The
ordering for display, then, is configured by the name-as-sort-order
attribute.

So what I’m thinking is:

  1. we add this to cs:name:

name-part = element cs:name-part { attribute name { “family” | “given” } }

  1. we change the expectations of cs:date so that children are unordered.

  2. we add an attribute to cs:name that will allow for proper localized
    formatting. I’m still a bit stuck on how best to do this, but I’m
    going to suggest adding ‘form’ so that one could do this:

In English, then, this would be rendered as …

Mar 3 1999

… with “Mar” in italics.

The problem is, in English we’d typically set-off the separate
month-day from year with a ", ". I’d expect in other renderings, like
“3 Mar 1999” that comma might not be there.

Where does the knowledge of localized ordering come from in this
construct? (I’m not being difficult, just dense; there’s a lot I
don’t know about localization.)

I could be missing the point, but … would it work to just treat date
forms as a special form of named macro that resides in locales
together with terms, and invoke them in or
with something like a singleton? That way,
you could provide standard named forms (full-short, etc), but tweak
them for the needs of particular styles by adding a full date
formatting definition to the style’s locale area for the target
language. Seems like it would work, but I could be missing the issue.

Frank

3

…

Where does the knowledge of localized ordering come from in this
construct?

The locale file.

I could be missing the point, but … would it work to just treat date
forms as a special form of named macro that resides in locales
together with terms, and invoke them in or
with something like a singleton? That way,
you could provide standard named forms (full-short, etc), but tweak
them for the needs of particular styles by adding a full date
formatting definition to the style’s locale area for the target
language. Seems like it would work, but I could be missing the issue.

I think that’s what I’m suggesting.

Bruce

4

…

Where does the knowledge of localized ordering come from in this
construct?

The locale file.

I could be missing the point, but … would it work to just treat date
forms as a special form of named macro that resides in locales
together with terms, and invoke them in or
with something like a singleton? That way,
you could provide standard named forms (full-short, etc), but tweak
them for the needs of particular styles by adding a full date
formatting definition to the style’s locale area for the target
language. Seems like it would work, but I could be missing the issue.

I think that’s what I’m suggesting.

Sounds good. I’m having trouble understanding the syntax of your
example, but that’s probably just my lack of experience with CSL
formatting showing. To avoid stirring things up unnecessarily, I’ll
wait for Elena’s response before asking questions.

Frank

5

Bruce’s plan sounds good to me, but it may take some time to come up
with a system that covers all formats for the date in various styles
and locales. I have some questions:

  1. How to deal with ambiguity in settings: for example, [form=“full-
    short month”] could mean: [Mar 3 1999] or [3 Mar 1999]

  2. How to reconcile style settings and locale settings. Here is a use
    case from this forum post:

  1. 2 autres exemples d’éléments liés à la langue du document/item:
  • pour un article de journal en français, on devrait écrire Le
    Devoir, 4 janvier 2009 /// pour un journal en anglais, The Gazette,
    January 4, 2009.

Localization is simple: [form=“full”] could mean [3 mars 1999] in
French and [March 3, 1999] in English.

But there could be an English style that required full form of [3
March 1999]–do we then devise new form attributes, something like
“full-day-month-year” and “full-month-day-year”?

  1. What does “full” mean (in [form=“full-short month”], for example)?
    Shouldn’t implementations display a full or partial date depending on
    the data in the field rather than CSL settings? Right now, most CSL
    date macros format dates so the day could be easily added or omitted
    depending on field contents–why would we then need to define a “full”
    or “partial” form?

  2. What will happen with dates such as these:

ca. 1950
1609?
1607-1608

And so on. Will the proposed localizations make formatting these dates
more difficult? There is a Zotero ticket for these cases: #888 ("is-date" should return "true" only if date parses cleanly) – Zotero

Thanks,
Elena

6

Bruce’s plan sounds good to me, but it may take some time to come up
with a system that covers all formats for the date in various styles
and locales. I have some questions:

  1. How to deal with ambiguity in settings: for example, [form=“full-
    short month”] could mean: [Mar 3 1999] or [3 Mar 1999]

  2. How to reconcile style settings and locale settings. Here is a use
    case from this forum post:

French Citation Style - Style de citation en français - Zotero Forums

  1. 2 autres exemples d’éléments liés à la langue du document/item:
  • pour un article de journal en français, on devrait écrire Le
    Devoir, 4 janvier 2009 /// pour un journal en anglais, The Gazette,
    January 4, 2009.

Localization is simple: [form=“full”] could mean [3 mars 1999] in
French and [March 3, 1999] in English.

But there could be an English style that required full form of [3
March 1999]–do we then devise new form attributes, something like
“full-day-month-year” and “full-month-day-year”?

  1. What does “full” mean (in [form=“full-short month”], for example)?
    Shouldn’t implementations display a full or partial date depending on
    the data in the field rather than CSL settings? Right now, most CSL
    date macros format dates so the day could be easily added or omitted
    depending on field contents–why would we then need to define a “full”
    or “partial” form?

  2. What will happen with dates such as these:

ca. 1950
1609?
1607-1608

I’m not sure if this is a good answer, but on Elena’s point 4, you
might just fudge these with a quoted escape. Zotero currently forces
numeric-capable fields that are enclosed in quotes to be handled as
strings rather than numbers (so is-numeric returns false even if there
is a number in the field content string). Giving similar treatment to
quoted date fields (rendering them as literal strings without
attempting to format them) would be easy to do on the computer end. I
can imagine all kinds of cases where this would need extra touch-up to
meet the requirements of a style. Should these be parsed and handled
on the basis of what they represent?

Frank

7

Bruce’s plan sounds good to me, but it may take some time to come up
with a system that covers all formats for the date in various styles
and locales. I have some questions:

  1. How to deal with ambiguity in settings: for example, [form=“full-
    short month”] could mean: [Mar 3 1999] or [3 Mar 1999]

The order gets configured in the locale.

  1. How to reconcile style settings and locale settings. Here is a use
    case from this forum post:

French Citation Style - Style de citation en français - Zotero Forums

  1. 2 autres exemples d’éléments liés à la langue du document/item:
  • pour un article de journal en français, on devrait écrire Le
    Devoir, 4 janvier 2009 /// pour un journal en anglais, The Gazette,
    January 4, 2009.

OMG; that’s insane!

Localization is simple: [form=“full”] could mean [3 mars 1999] in
French and [March 3, 1999] in English.

But there could be an English style that required full form of [3
March 1999]–do we then devise new form attributes, something like
“full-day-month-year” and “full-month-day-year”?

That probably wouldn’t work here. This one is a mess. First, you’d
need a way to specify the locale you want, so that the correct month
term gets printed (“January”). We can’t do that now.

  1. What does “full” mean (in [form=“full-short month”], for example)?

year + month + day (rather than just month + day, OR year)

Shouldn’t implementations display a full or partial date depending on
the data in the field rather than CSL settings? Right now, most CSL
date macros format dates so the day could be easily added or omitted
depending on field contents–why would we then need to define a “full”
or “partial” form?

  1. What will happen with dates such as these:

ca. 1950
1609?
1607-1608

And so on. Will the proposed localizations make formatting these dates
more difficult? There is a Zotero ticket for these cases: #888 ("is-date" should return "true" only if date parses cleanly) – Zotero

I think these are orthogonal issues. Ideally, we’d probably add some
explicit support for these concepts to CSL (particularly the first
two; circa and ‘my wild guess’).

Bruce

9

Ditto previous note, but I’ll just ask this:

Does this really solve the problem?

Say we have three types of date formatting in a style: year only,
month-day only, and full.

Localization needs to be applied to the latter two.

Bruce