Btw, the date-helper.js require huge refactoring. Currently it in mootools style ?

Would be really cool to get that into 4.0.0, but it would require to make an exception from the language freeze and I'm not the one who can do that.

but it would require to make an exception from the language freeze

If choose between: make an exception for 2 new strings or maintain 50 js files until Joomla 5
I would choose first one :)

Same for me.

Btw, the date-helper.js require huge refactoring. Currently it in mootools style

@Fedik don't waste your time with this whole legacy thing. Temporal https://github.com/tc39/proposal-temporal is coming to all browsers...

@Fedik thanks for this pr, what I think is that the additional number xml value is an overkill. If I read it right then the jalali calendar always use the localized numbers. It would be great if you hardcode them at any level (in JS or PHP) so the translators doesn't need to convert them. If we really needed we can introduce it again but for now it's only work for all translators.

If you have done this change (if possible today) I get's tested today and merged before RC tomorrow.

If I read it right then the jalali calendar always use the localized numbers

I know about jalali calendar as much as you ;)
I tried to keep original things.

If we really needed we can introduce it again but for now it's only work for all translators.

Not for all, only who need this number, it optional metadata, I can remove it from En (was just an example).

It would be great if you hardcode them at any level (in JS or PHP)

Yeah, can try, maybe in jalali/date-helper, for now. Need to check.

@HLeithner I have hardcoded them in to date-helper.js for now. Seems works.

don't waste your time with this whole legacy thing

@dgrammatiko does Temporal support local numbers, local calendars etc?
I did not read full specs, bored thing to do ?

@Fedik perfect thanks I think I found some code style issues but will test it today

I think I found some code style issues

Drone did not found any, should be good ;)

@HLeithner I have hardcoded them in to date-helper.js for now. Seems works.

Can we reconsider this and probably revert it?

Why? Well, looking forward here in few months all browsers will support a large number of calendars that will require these numbers so it's better to keep the ref in the ini now and for the rest of V4 life.

Here's a list of supported calendars: https://github.com/js-temporal/temporal-polyfill/blob/f67e31228aa79966c2de51f181ebbf3b2d40c0f5/lib/calendar.mjs#L1968-L1983

And here's a list with all the languages with different support of the digits:
https://en.wikipedia.org/wiki/List_of_numbers_in_various_languages

I not really can find how that numbers used there

I not really can find how that numbers used there

They are not used there, but if you start supporting languages/calendars that support different numerals then Joomla's front end needs those numbers (eg you need to parse and display those numbers in the front end, so you have to define them in the PHP, since everything is driven by PHP)

@HLeithner I have hardcoded them in to date-helper.js for now. Seems works.

Can we reconsider this and probably revert it?

Why? Well, looking forward here in few months all browsers will support a large number of calendars that will require these numbers so it's better to keep the ref in the ini now and for the rest of V4 life.

Here's a list of supported calendars: https://github.com/js-temporal/temporal-polyfill/blob/f67e31228aa79966c2de51f181ebbf3b2d40c0f5/lib/calendar.mjs#L1968-L1983

And here's a list with all the languages with different support of the digits:
https://en.wikipedia.org/wiki/List_of_numbers_in_various_languages

I see more work for our translators then benefit, if you say it's in the browsers (Safari on mobile and android on mobile for devices 5 years old ;-)) it would also mean that our current policy needs about 1-2 years (maybe faster I think depends mainly on safari).

Beside that I see the policy more like current version - 2 from release date of 4.0 but I think that's open for discussion. ymmv

Also I think the numbers shouldn't be in the xml file, we have J1 J2 .... which can/should be used for numbers right? Adding string to the xml which is not meta should be a translate able string in the ini file.

I also think we have to rework the complete calendar if the browsers support it new api (even with of we want to use this heavy polyfill)

if you say it's in the browsers

It's not yet but also there's a polyfill so it's not really related to the browser version (depending on the implementation of course)

Also I think the numbers shouldn't be in the xml file, we have J1 J2 .... which can/should be used for numbers right? Adding string to the xml which is not meta should be a translate able string in the ini file.

My point is that Joomla needs to have on the languages the literals for the digits, if they are there already then a simply array.map or whatever will do it

Okay. I think if someone will implementing it for Joomla, then we can add <numbers>۰,۱,۲,۳,۴,۵,۶,۷,۸,۹</numbers> metadata back, or in xx-XX.localise.php (or any other place).
I doubt it will be earlier than 4.5 ;)

Adding string to the xml which is not meta should be a translate able string in the ini file.

It still a numbers, I would not do it in INI file. It should not be overridable as any other text string.

Okay. I think if someone will implementing it for Joomla, then we can add ۰,۱,۲,۳,۴,۵,۶,۷,۸,۹ metadata back, or in xx-XX.localise.php (or any other place).

Wasn't that the reason that the .js files were introduced in the first place?

I also think we have to rework the complete calendar if the browsers support it new api

It would be better to fix the essential blocks of Joomla instead of keeping adding debatable (not well thought) new features...

Anyways that was my 2c, I guess the planning goes up to J4 initial release...

We can add language string at anytime so adding the numbers as meta or ini string can be done also in 4.0.1 if it's not used or with a fall back. But what I try to avoid is a broken calendar because a translation is incomplete.

Anyway @wilsonge may have a better idea or another vision

Wasn't that the reason that the .js files were introduced in the first place?

There was no files for old calendar, we had fancy inline js code ;)
And these languages had some "special" hack, they override whole calendar.js in past. If I right remember.

There was no files for old calendar, we had fancy inline js code ;)
And these languages had some "special" hack, they override whole calendar.js in past. If I right remember.

Well, the old code (dated back to 2006) was bad, not that the current (2016-17) one is either modern or better ?

It seems the Jalali calendar is not right yet.

It works now after the last commit, i.e. I can see a calendar with their numbers and names, but the year, month and date seems to be different.

You can quickly see that by the year (but day and month are different, too). Currently they have year 1400.

Before patch:

After patch:

The missing translation of the "Close" button could be related to the language pack. I had to use the 3.9.28 language pack and install it with upload & install because there is no Persian language pack for J4 available yet.

hm hm

Maybe we should change this here to "jalali"? https://github.com/joomla/joomla-cms/pull/34870/files#diff-62814d248322d614864f995a77aab270e5140f3be39a9150c35070f05932b989R294 ... I know, it was 'gregorian' also before your PR, but maybe now it works differently?

Hmm, but why does the year show 1900 after the patch and not 2021? Maybe I've made something wrong.

need to check

I see, jalali have different years counting:

hmhm, that a bit a problem ?
I think it need to come from lang metadata, the same as <weekend>

but why does the year show 1900 after the patch and not 2021?

if you change

'data-min-year'        => $minYear,
'data-max-year'        => $maxYear,

to

'data-min-year'        => 10,
'data-max-year'        => 5000,

in the calendar layout, does it work for you after that?

but why does the year show 1900 after the patch and not 2021?

1900 is the lower boundary, the value is 14** so it becomes 1900...

1900 is the lower boundary, the value is 14** so it becomes 1900...

Yes, seems so.

I have changed min year to 1000, it showing 1400 for me now

I have changed min year to 1000, it showing 1400 for me now

@Fedik Right, here too ... but I still have different dates on J3 and J4, the latter with your patch. And I have the same date and time in database.

I see 1410 and not 1400 for the year.

For jalali testing:

From English backend set the field values:

2021-07-26 10:00:00
2021-08-27 18:00:00

Open Persian backed, and make sure the dates is:

۱۴۰۰-۰۵-۰۴ ۱۰:۰۰:۰۰
۱۴۰۰-۰۶-۰۵ ۱۸:۰۰:۰۰

Which is:

1400-05-04 10:00:00
1400-06-05 18:00:00

I still get different month names here.

I still get different month names here.

In which case? when tried my test, or something else?

Ok here my results comparing 4.0-dev without and with this PR:

• Clean, current 4.0-dev without this PR applied
  

• Branch of this PR
  

Following differences:

• With the PR, the "Close" button and the "wk" column label for the week numbers are not translated.
• The month name is different, but this could be due to long and short month names or abbreviations.
• The weekday column labels are different, but this could be due to long and short day names or abbreviations.

I've tested the 2 installations in parallel with same server time zone UTC.

Saving a new article at the same time resulted in the same created date in database.

Modifying the created date in the calendar by selecting tomorrow, hour 3, minute 2 and saving in database resulted in the same datetime in database.

I haven't tested yet with other time zones than UTC in the server settings in Global Config.

So beside the differences mentioned above I haven't found anything.

Weird results in previous tests might have come from changes in code (minimum date).

Other timezone works, too.

It seems the different month name at the top is not due to abbreviation. See https://en.wikipedia.org/wiki/Solar_Hijri_calendar#Months

To me it seems that my 2nd screenshot with the patch applied shows the name of the 7th month and not the name of the 4th month.

But maybe it just looks similar, I don't know.

I see, the months in https://github.com/joomla/joomla-cms/blob/4.0-dev/build/media_source/system/js/fields/calendar-locales/fa-ir.es5.js actually in opposite direction

and seems, the same for days

Maybe javascript also has an RTL way, like CSS? ;-)

@richard67 @Fedik probably the translation is really bad:

In the old file their days were starting with saturday instead of sunday as in every other language, so maybe this needs to be adjusted for the helper (?). Same goes for the months, in the old file starting with march...

window.JoomlaCalLocale = {
 	today : "امروز",
 	weekend : [5],
 	wk : "هفته",
 	time : "زمان",
 	days : ["یکشنبه","دوشنبه","سه شنبه","چهارشنبه","پنجشنبه","جمعه","شنبه"],
 	shortDays : ["یک","دو","سه","چهار","پنج","جمعه","شنبه"],
 	months : ["فروردین","اردیبهشت","خرداد","تیر","مرداد","شهریور","مهر","آبان","آذر","دی","بهمن","اسفند"],
 	shortMonths : ["فروردین","اردیبهشت","خرداد","تیر","مرداد","شهریور","مهر","آبان","آذر","دی","بهمن","اسفند"],
 	AM : "ق.ظ.",
 	PM :  "ب.ظ.",
 	am : "ق.ظ.",
 	pm : "ب.ظ.",
 	dateType : "jalali",
 	minYear : 1268,
 	maxYear : 1458,
 	exit: "بستن",
 	clear: "پاک",
 	localLangNumbers: ["۰","۱","۲","۳","۴","۵","۶","۷","۸","۹"]
 };

In the old file their days were starting with saturday instead of sunday as in every other language, so maybe this needs to be adjusted for the helper (?). Same goes for the months, in the old file starting with march...

In fact the "every other language" is wrong.

The official start of the week e.g. in USA is Sunday, but in Germany it is Monday.

In Iran, Friday is like our Sunday, it is their holy day, and they have off and start work on Saturday.

yeah, need to look, need some kind of resort to keep older order

yeah, need to look, need some kind of resort to keep older order

Ah, the array of days/months is in reverse order, just do a [].reverse() and should be fine, hopefully

And not all years begin Jan 1.

That's why we have settings for this stuff in the language metadata.

Hopefully with Joomla 5 we will have a common calendar and universal time system for all the planet, like they have in Star Treck.

If J5 takes as long as J4 did, the changes for that are not so bad ;-)

In fact the "every other language" is wrong.

You misunderstood me. The code is creating an array from the days/months, this needs to account for all these little differences, my comment about the translation been bad was wrong. The problem is the array of days/months is not the same for every language, different starting day/month should be accounted

And not all years begin Jan 1.

I will changed the rule, everyone should start new year in 1 March ?

I did not seen that calendar use this stuff from the language metadata.

I will changed the rule, everyone should start new year in 1 March

Can we make it like August first, so we start with vacations ?

I did not seen that calendar use this stuff from the language metadata.

It was correctly hardcoded in the JS, that's why

just do a [].reverse()

that was the plan

that was the plan

Actually, that will not solve all the cases, you need to rebuild the array according to first day

PS I don't know if we have a 1st month variable saved anywhere so that might be also required to reshuffle the months

If compare this 2 files,

https://github.com/joomla/joomla-cms/blob/4.0-dev/build/media_source/system/js/fields/calendar-locales/fa-ir.es5.js
https://github.com/joomla/joomla-cms/blob/4.0-dev/build/media_source/system/js/fields/calendar-locales/en.es5.js

it juts a reverse

hm, no

The "weekEnd" in the Persian metadata xml is wrong or I don't understand it. But that's not the problem here, I only noticed that.

Please dont forget that users can and do make changes in their language files. I do it all the time

		<firstDay>0</firstDay>
		<weekEnd>0,6</weekEnd>

Please dont forget that users can and do make changes in their language files

yes it there:

I have changed the order,
I mean the World order

I hope it is better now :)

@Fedik something like

[...[0,1,2,3,4,5,6].slice(5), ...[0,1,2,3,4,5,6].slice(0, 5)]

// Pseducode
[ ...days.slice(firstDay), ...days.slice(0, firstDay)]

should do it

@Fedik Moving months 1 and 2 to the end makes sense to me since their year starts in what is our March, and the language strings are 1 to 1 translations, so always start with our month 1.

But why the days are reverse order I don't get, except that was a hack in the old calendar js to cater for the RTL direction of the weekday columns.

Keep it generic:

	Date.daysToLocalOrder = function(days, firstDay) {
 		return [ ...days.slice(firstDay), ...days.slice(0, firstDay) ];
 	};

Same for the months. Don't fix just the Jalali, as these differences might exist in other languages

But why the days are reverse order I don't get

yeah, it just to keep old behavior,
I do not really want rewrite whole calendar now ;)

btw, firstday it means, first day? or number of first months?

btw, firstday it means, first day? or number of first months?

It seems to mean first day of the week, with 0 being Sunday and 1 being Monday at least for Gregorian calendar.

In English language meta data it is 0 and in German 1, because in Germany we start counting the week with Monday.

btw, firstday it means, first day? or number of first months?

Should be like sunday for most countries, saturday for persian, it's the index of the [sun, mon, ... sat]

Should be like sunday for most countries

@dgrammatiko Again: This is wrong. In Germany or France we start the week with Monday because we are based on non-religious counting, while e.g. in USA the week starts with Sunday even if they start to work on Monday like we do here because they stick with the Bible whish says Saturday was the 7th day.

I think the reverse order of the days for Persian really might come from RTL. It might be worth to check the Arabic old calendar js.

@richard67 ok bad explanation. Another take:

• From PHP the days array is sunday till saturday
• We also have first day as an index of the above array
• Final days array that the calendar will use is an array that starts with the index day etc

It might be worth to check the Arabic old calendar js.

oh, it also reversed, the days
https://github.com/joomla/joomla-cms/blob/4.0-dev/build/media_source/system/js/fields/calendar-locales/ar.es5.js

oh, it also reversed, the days
https://github.com/joomla/joomla-cms/blob/4.0-dev/build/media_source/system/js/fields/calendar-locales/ar.es5.js

Then it really could be an RTL hack because the calendar field can fill the weekdays only from left to right.

So for the months do as proposed by @dgrammatiko and for the weekdays do a reverse if direction of the language is RTL.

seems need to reverse all RTL languages for days,
will look at it tomorrow

return [ ...days.slice(firstDay), ...days.slice(0, firstDay) ];

for days it just a reverse, rest about firstDay is doing by calendar scrip, if I right

@dgrammatiko P.S. The United Nations decided in 1978 that beginning of the week is Monday. ISO standards do the same, https://de.wikipedia.org/wiki/ISO_8601 . In fact the majority of all countries starts the week with Monday.

for days it just a reverse, rest about firstDay is doing by calendar scrip, if I right

Probably you're right, it's been a long time since I checked that code...

I have changed the order again,
it seems better now, would be cool if someone confirm :)

For testing Persian language with Jalali calendar it needs to download the 3.9.28 language pack and install that with the extensions installer with Upload & Install: http://joomlacode.org/gf/download/frsrelease/21015/166107/fa-IR_joomla_lang_full_3.9.28v1.zip

unfortunately I'm busy with work now but will try to test later if still necessary.

The calendar works well for me on English, French. For Persian , I can still select a date and see the value saved, but I do not know how to check if it really works.

@joomdonation try some dates and check them against https://www.iranchamber.com/calendar/converter/iranian_calendar_converter.php

Additionally can try this test: #34870 (comment)
To be sure the values is correct between gregorian and jalali calendars.

I think I understand now the reason for the reverse day order: Even if Persian is an RTL language, they show numbers like e.g. 1400 for the year, but also the days in the calendar from left to right. But the calendar is RTL and so would show the days from right to left. The reverse order hack (that's how I call it) compensates for that.

Then you should use direction=ltr

For Russian the calendar shows differences in the grammatical case of month names, see example for today, left hand side without and right hand side with the PR:

@Fedik Do you know Russian language and how their Calendar should be?

I think it is translation issue, their current translation fit for 27 July 2021
but do not fit for July 2021 or July

Tamil calendar is exactly same with and without this PR.

For Persian I still find differences.

Month names look completely different. But that could be related to Arabic versus Farsi language being used in calendar, I don't really know.

Day names are different, but the shorter ones with the PR look as if being just the 1st letter of the longer ones without the PR.

But there is also a difference in weekend.

Left hand side without and right hand side with the PR:

This also may come from translations.
Did you tried translate displaying result, does it show the same month?

I'm going to get this in because the best way to deal with this is to get the translators testing with the RC tonight. Also we need to give them as much time as possible to do the translations.