Last modified: 2014-11-17 22:07:00 UTC
When displaying time values, an assumption regarding the calender model is applied: The calendar name is appended to the date for every date in ]1581, 1930[, for dates <= 1581 that are specified in the Gregorian calendar and for dates >= 1930 that are specified in the Julian calender. (see HtmlTimeFormatter.php) This results in having "default" calendars for dates <= 1581 and >= 1930. At least in some way, users need to be aware of those "default" calendars which would become even more confusing as soon as other calendar models are implemented. Anyway, these default calendars are not even enforced when editing. When adding a date prior to 1581, the Gregorian calender is selected by default which would display the calendar name next to the date. Switching to Julian simply removes the calendar name in superscript. While the UI behaviour is correct, the UI concept is misleading.
Conversion between Gregorian and Julian had been done back when the TimeValue was managed in the front-end. It would definitely by nice to be able to have some widget/gadget that would show/allow converting a value. But some observations more specific to this bug: UI sends a value to the back-end parser. Back-end parser always returns Gregorian value since it does not have the specific time ranges implemented. The parsed value is posted to the formatter which, of course, returns the date in the Gregorian calendar since that one is specified in the parsed value. The UI itself does not feature any logic regarding calendar management anymore. Options: - Implement "defaults" in the parser which would mean having very specific (kind of "magic") logic in the parser. - Implement "defaults" logic in the front-end overwriting the Gregorian calendar returned by the back-end parser as long as the Gregorian calendar has not been selected specifically. That would mean to have the "defaults" logic in front-end and back-end (since still needed in back-end formatter). - Evaluate if having multiple "defaults" is worth having the effort at all.
We basically have two bugs about the same issue (the other one being #70398). This one is high/major, the other one highest/major (the only one with "highest" priority and tagged "frontend"). Can we, at least, figure out how that is going to move on?
Denny: We talked about this. Can you have a look and comment with your thinking on it please?
Here is how the UI should work as long as we support only proleptic Gregorian (G) and proleptic Julian (J) calendars: - when entering a date before 1581, it should understand that date as J (and display a not too obvious option to switch to G). - when entering a date between 1581 and 1930, it should understand the date as G per default and allow to easily switch to J instead. - when entering a date after 1930, it should understand the date as G. Although there is no real use case for it, it allows the user to switch to J, but it shouldn't be too obvious. - if a user has explicitly chosen a calendar for a value, it should stick until the user changes it explicitly again - if a user is editing a date, the calendar should stick until the user changes it explicitly I think bug 70398 is a duplicate. It should be merged here and the priority here should be raised to highest. This is currently doing damage to Wikidata. Whether the implementation is happening in the backend or frontend, I do not really care. To make sure: the calendar model only refers to the display (and editing). It always displays (and edits) in the explicitly given calendar model. The backend eventually *always* saves the date in G. I am happy to discuss this as needed.
I am in for that--it is the same behaviour than it was before, although, back then, the front-end parser applied conversion when changing the calendar (which was sort of strange). When having additional calendars, the behaviour should most likely be the same: The parser detects which calendars the date may match to. While picking the "most likely" (...), there should be hints to switch directly to one of the other calendars. However, in my opinion, this mechanism of, basically, guessing the calendar cannot be mapped properly on displaying dates, even more when having in mind that there really should be more than Gregorian and Julian. The basic options would be to either have one "default" (Gregorian) only or have no default at all. First would result in dates before 1581 entered in Gregorian not explicitely being annotated about the date being Gregorian (since, on the contrary, all Julian dates would feature an annotation, regardless of being before or after 1581). Latter would result in always displaying the calendar name next to the date (even for Gregorian dates after 1581). Applying any logic guessing the calendar when displaying a date (which is what is done at the moment) feels like a time bomb issue. Although, for an optimization, we could probably apply using "Gregorian" as default in the time range Gregorian was used, exclusively. Eventually, having no default calendar for dates <= 1581 (always display calendar name), and default to Gregorian for dates > 1581 (display calendar name when not Gregorian). To me, that appears to be the most practical solution and avoids generating confusion about having multiple defaults.
OK, I will not fight for the multiple defaults even though they make total sense to me. But displaying the calendar model always does not hurt. But the calendar model should default to the right model when a date is entered, as stated above, as just discussed with Henning off-Bugzilla, and allow the user to explicitly switch. No translation / transformation of the date should be done when switching the calendar model. It merely switches the calendar model, but the nominal value stays the same.
*** Bug 70398 has been marked as a duplicate of this bug. ***
(In reply to denny vrandecic from comment #4) > Here is how the UI should work as long as we support only proleptic > Gregorian (G) and proleptic Julian (J) calendars: > - when entering a date before 1581, it should understand that date as J (and > display a not too obvious option to switch to G). Gregory XIII decreed that 4 October 1582 be followed by 15 October 1582 and this was the earliest the change was observed. If you want the default to be governed only by the year, then Julian should be the default for years less than 1582, rather than 1581 as stated in comment #4. This is probably best, because dates are often given to a precision of one year.
It is best to display "Julian" next to all dates in that calendar, since many users only have a vague notion of when the Gregorian calendar first entered into force. Indeed, most dates I have examined in Wikkidata before 1752 that were stated or implied to be Julian in Wikipedia were incorrectly stuffed verbatim into Wikidata, suggesting many users never heard of the Julian calendar.
Aye. It would be great if all bot requests adding dates before 1920 would be required to demonstrate that they understand the two different calendars, and to explicate how they are handling it. Just reading any dates from the article and Charlesmagne and writing it into Wikidata as proleptic Gregorian because this is the default that happens to the API call is just bad. At least human edits will get usually nudged to be correct by the workflow implemented here. But bots don't get (and should not get) the same kind of nudge.
