These are two alternative layouts of a calendar on a hebrew-language site. Hebrew is written from right to left. Should we display the dates in the same way that the language is written (RTL), or should we display the days of the week in the same way that dates are usually displayed (LTR)?
The problem is that the days of the week are given on the green bar at the top of the calendar, and reversing their order looks just as confusing to the native speaker, as reversing the order of the dates.
That's an interesting question. But I think any definitive answer will just be ignoring context and some of the dimensions involved.
Here's a breakdown:
You'll find Hebrew and Arabic calendars that use either paradigm. Can't tell at which ratio, but a quick online search (especially if you search for the english translation) will reveal both.
The examples you have provided are Gregorian calendars, with Hebrew titles - the month starts on the 1st and ends on the 31st. This suggests users will already be familiar with the Gregorian calendar.
A Hebrew calendar will revolve around the Hebrew months and not the Gregorian ones. This will be (as one would expect) RTL:
(This wasn't easy to find, yet it has all the Gregorian components.)
If we take Israel as an example, the majority of people have no idea what Hebrew day or month it is, and may only know the year because it is advertised around the Jewish new year. Most people won't be able to tell you their Hebrew birthday. Nearly every date communicated is Gregorian.
The exception to this is the orthodox:
Which are (surprise?) only 10% of the population and still most have mobile phones so they are exposed to the Gregorian calendar (to some extent).
Which leads us to the next point.
People who's main language is RTL, are still exposed to LTR content.
Probably first and foremost are numbers (which are LTR in both Hebrew and Arabic, even when Arabic numerals are used). Maths - as in equations, or how you'll be taught and develop solutions in exams - are also LTR.
Many of these people are exposed to other LTR languages (English, French in north Africa, etc.).
I'll be VERY surprised if in financial meetings - let it be in Egypt, Israel, or Lebanon - the spreadsheets are RTL and the time axis in graphs follows the same direction. But exceptions do exist:
So despite being RTLs, LTR orientation is something most poses.
Regardless of LTR orientation, it is worth noting that when it comes to direction inversions of lists - we don't find it too tricky.
Here are the first 10 prime numbers, RTL:
29 23 19 17 13 11 7 5 3 2
Can you tell which is the fifth prime number? Would it be any easier had the list been LTR?
This is in contrast to...
... sdrow ni srettel fo noisrevni ...
... where the brain loses the start-end/predictive shortcuts and resorts to reading each letter (at least a non-trained brain - there has been some research on this).
The argument here is, that if people have to read a list in inverted order, you may just as well make them do this on the day-of-the-week (of which there are 7), than on the day-of-month (of which there are approximately 30).
Another important question is how people use this visual representation of a month.
Again, a key question is whether the Gregorian calendar is the basis for (non-visual) communication.
I'd say there are two primarily use case:
Which one do you think is more common?
There are obviously more use cases - I'll let the reader figure these out.
I think that if you read again through each section, given that your target audience is just generic RTLs, it seems more reasonable to have the day-of-month LTR (as they would be on an English Gregorian calendar), and have the days-of-the-week 'inverted'.
Did languages switch to LTR in order to reduce smudging of ink? Answer.
TL;DR: No. I don't think it's necessary to consider language directionality when it comes to a grid calendar view. Having said that, if your specific user-base has a dominant calendar they use, and it has a certain layout (even if it's a circle), you may want to go with that. Having said that, with the prevalence of certain calendrical solutions already on the market, chances are the days of the week will be left-to-right.
I'm not sure one should try to take language direction into consideration when designing a calendrical layout; they are completely different visualization experiences.
When users interact with a calendar they are not reading a series of glyphs grouped together in succession. Instead, they are hopping around a grid attempting to locate a date, which they pan up to see what day of the week it is. Whether that day is first or last makes little difference. They might start by looking for the day, which, again, the order means precious little because they will scan the seven or so options to find the one they are looking for, and go from there.
Most Asian systems of writing can be written horizontally or vertically, but the calendar is not a book, it's more like a data visualization; completely different experience.
Going back to the Calendar for macOS, they give you the option to have an alternative calendar displayed; none of them change the order of the days of the week.
Checking out solutions to the same problem (calendar in multiple languages), we'll finish the exposition with the Calendar app for macOS again (because Apple tends to put a lot of thought and research into their UX to keep up that customer satisfaction rating). At no point does the order of the days of the week change...only the glyphs representing the dates, month, and year. (Note: The names of the days of the week do not change either, which indicates the possibility that these are ubiquitous as well; or, at least, easily mapped independently from the region.)
Given that evidence and logic, I would say, no. The directionality of language does not need to be taken into consideration when creating a calendar because it is not the written word, it's more like a data visualization. So, as a UX problem, consider what your users are trying to accomplish. Is a grid of days really the best choice? Or, is it just that it's consistent with what users already know?
Maybe a set of spinning selectors would be better. Maybe a list.
