Closed ggeisler closed 4 years ago
If we do the preferred solution, how should we handle user input? Will they be typing H + BH (and, what variants of that do we need to support?)?
I think we should opt for the "potential lesser solution". I think having users type letters will be just trading one UX problem for another. This is not perfect but it is an improvement. I think we should also do the same thing to the Gregorian calendar view for consistency (e.g. BCE and CE).
@cbeer Good point, maybe that is reason enough to go with the lesser solution as @jacobthill suggests.
I'm on the fence about whether we should do the same thing for the Gregorian calendar (which is why I made this ticket specific to the Hijri version of the component). It would be consistent within DLME, which feels right, but on the other hand aren't people who use Gregorian calendars familiar with the meaning of negative dates in a component like this? But I suppose if we can technically do it for Hijri, it is worth doing for Gregorian and see how it feels.
Yeah my thought is that there really is no difference between Hijri and Gregorian in this respect except that people are more likely to understand negative to mean BC. There is a precedent with Hijri. Its just not as commonly used because the Gregorian calendar is still in use and people can convey the same idea by referring to the Gregorian year instead of (e.g. 300 years before the Hijra). I think we want the UI to educate people in this respect and having consistency between the calendars will, hopefully, contribute to this end without having to add flash messages or other things to convey the point.
@jacobthill @ggeisler I've implemented this in English. But I'm curious, how should this look in Arabic?
@mejackreed You mean how should the "BH", "H", "BCE" part of the labels display in Arabic?
If so, let's see if @jacobthill knows. I'm not really sure if there are Arabic translations commonly used for those, and if so, will they reasonably fit into the limited horizontal space we have to work with.
Yes exactly that question, thanks for clarifying Gary.
I have a message out to QNL.
This is what we should use:
CE: م H: ه BCE: قبل م BH: قبل ه
To the left or right of the digits?
I've implemented it one way.. not sure if this is correct, but maybe something to react to?
@mejackreed the green font seems correct but the black font at the bottom of the histogram should have the number to the right of the Arabic text
Which font are we using here? I think this was one of the problems mentioned: the م which indicates 'Milady' (Gregorian) is missing the tale that hangs down which makes it look very similar to the ه which indicates Hijri.
This is the current font deployed in our environments, Mada.
I'm creating a new ticket for this to clearly separate this issue from:
As noted in #845, the concern is that (if I understand correctly) the Hijri calendar starts with year 1, so displaying a value like "-500" as a label on the x-axis of the date range graph and as a value in the date range inputs doesn't really make sense.
Preferred solution
It's not clear to @jacobthill and I what is technically feasible but here is our preferred solution:
(Ignore the flash message shown next to the facet title; this would be very challenging to display nicely in the sidebar version of the facet, and I'm hoping it is not really necessary.)
Potential lesser solution
This is not at all ideal, but I'm worried that the input fields (item 3 above) might be more challenging than the other items, because it needs to be strictly numeric. If that's true, we might be able to get away with just doing:
and leaving the input fields displaying a minus sign, to keep the field numeric-only. It would be very awkward to use different formatting for the input fields versus the labels, but perhaps it will nonetheless be clear to the user (because the numeric values will still match) that "-500" in the input box is shown as "500 BH" on the x-axis.
I really don't like this solution, but bring it up as possibly better than doing nothing at all, if we can't do all of the preferred solution.