As a user, I would like to see historic and converted dates on the document details page so that I can easily find date information when it is known.

[rlskoeser]

testing notes (qa)

On the QA public site, check document detail pages for documents with historical dates, converted dates, and any combination/lack thereof, and confirm:

• The dates are present on those documents' detail pages (if they should be)
• The dates are formatted correctly

dev notes

• create a method on Document to render historical date combining display form of doc_date_calendar and doc_date_original
• Update document details template to display original and converted document date if the fields are set.

Follow the latest version of the document details designs for placement and labeling.

In the html, let's wrap the whole thing (historic and converted date text) in a time element and set the converted date as the datetime attribute.

[richmanrachel]

@rlskoeser and @blms - could we perhaps a comma before the type of calendar so it's clearer? Here's how it looks now:

[richmanrachel]

@blms - I can't tell if I'm just running into problems because I was attempting to do this quickly before turning to other work, but I'm not seeing document dates on the test site right now. Was there a refresh of the test data? Because I was adding dates myself when testing the other day, since it's hard to find them on the site, but even when I was doing that today the refresh (and hard refresh) were not making the added dates show up.

[blms]

@richmanrachel That's odd! I don't know of any data refresh, though maybe there was one—@rlskoeser?

In any case, you should be able to see newly added dates either way. Can you provide an example PGPID for one you tried to add that didn't show up?

In case it helps, here's an example of one that is showing up successfully, both on the admin and the public site:
https://test-geniza.cdh.princeton.edu/admin/corpus/document/16798/change/
https://test-geniza.cdh.princeton.edu/en/documents/16798/

[rlskoeser]

@richmanrachel I haven't refreshed the test data in a while — LMK if it would be helpful.

I did notice that the site url had not been set correctly in the db, so if you were editing documents and following the 'view on site' link, it would have taken you to the production site. (Sorry about that!)

here's a list of sample documents with dates: 23729, 1715, 35163, 8394, 34913, 19138, 35159, 32167, 30735, 30733

[richmanrachel]

@rlskoeser - you're exactly right, the view on site link was pulling me onto the production side. Thank you so much for the list of PGPIDs

It looks pretty good! I want @mrustow's opinion before closing, though. I'll send her some screenshots.

[mrustow]

First off: I LOVE IT! The public site date display is wonderful.

Three minor tweaks — sorry not to have chimed in on this above:

1. Can we capitalize only the first word in headers like Document Date and Primary Languages --> Document date and Primary languages
2. Hijrī --> AH, and remove the comma between the year and the era, so "423, Hijrī (1031/32 CE)" --> "423 AH (1031/32 CE)" BUT
3. Abbreviate the Seleucid era as well, so "18 Nisan 1493 Seleucid" --> "18 Nisan 1493 Sel." (no comma here per CMS).

It occurs to me that it could be user-friendly to have a pop-up info bubble on the public site (are we doing those?) defining the various eras:

CE: Common Era, derived from the Christian calendar and in common use today
AH: anno hegirae, the year according to the Islamic calendar, calculated from 622 CE with a lunar year of 354 or 355 days
Sel.: anno graecorum, or Seleucid Era; in Jewish documents, the Era of Contracts (מניין שטרות, minyan sheṭarot), calculated from 311 BCE

The admin interface stays the same, right? Wasn't sure if I should be eyeballing that for something new.

[blms]

Thanks @mrustow! That's very helpful. There are two more calendars: Kharājī and Anno Mundi. How should those be abbreviated? I know Anno Mundi should probably be "AM"…

@rlskoeser Does it make sense to implement abbreviations as just a dictionary constant, or should we use ORM models? I'm leaning towards the former, and thinking we should make a note there and in the calendar choices to remind people to update both at once when adding a calendar. But not sure if that's a good approach.

[rlskoeser]

@blms let's create a dictionary on the Document object* keyed on the constants we already have defined, and then implement a calendar display method that returns the abbreviation. Also! Those labels and abbreviations should probably be flagged for translation, they are currently not.

* side note: our Document object is getting enormous and unwieldy; am wondering about segmenting out doc date functionality and fields as a mixin just to help organize the code some...

[mrustow]

Right about anno mundi = AM. There's no abbreviation for kharaji ... I think there are only 5 ppl on earth who are aware of its existence ... here's text for each info link:

Anno mundi: the Jewish calendar, counted from the date of creation.

Kharājī: the fiscal calendar. Either in sync with the hijrī year (AH) or up to several years behind it, depending on the year. The difference was due to delays in tax collection.

[blms]

@mrustow @richmanrachel The comma has been removed! Work on the abbreviations and explanations has been split off into separate issues: #828 and #829. We will just need a sign-off here on the presence of the dates and removal of the comma, and then the remaining work can be evaluated separately.

[mrustow]

signed off!