Are you sure it's an RTL issue. Not at my pc but looking at the screenshots it's a jalali calendar so even the markup could be different

Are you sure it's an RTL issue. Not at my pc but looking at the screenshots it's a jalali calendar so even the markup could be different

@brianteeman Yes, it is an RTL issue. If I patch the German site language to RTL in the langmetadata.xml, I get the same styling as shown for the Persian calendar in my screenshot.

The reason is that PR #46811 added a calendar.scss to the template, which imports the calendar.css from the system/css/fields folder. But in the same folder is also a calendar-rtl.css. I think it needs to add a calendar-rtl.scss to the template which imports that file and then does the same thing, setting the colour variables right.

Ah ok then you are correct. We probably don't need that separate RTL file

Ah ok then you are correct. We probably don't need that separate RTL file

That would of course be even better, if we just can get rid of it.

I will do it tomorrow

It is NOT correct to add the fix to the existing RTL css. That file is wrong in many places and we really can do it all in a single calendar.css BUT that requires changes in a few other places. There is also a bug currently in the calendar when the time is displayed so I will fix all of that at the same time.

This is all fixed with #46910

Yes, the issue will closed automatically by GitHub when the PR is merged.

no it wont as that change has not been merged and anyway my message was for those people READING this issue on the issue tracker who would never know there is a pr without my comment

They will know if they know that below the title of the issue, the linked PR is shown, if any.

And in the issue list this also can be seen:

In the PR you can see the linked issue:

And in the list of PRs that can also be seen:

When the PR is merged into the default branch (currently 5.4-dev), the issue is closed by GitHub with a special message:

For other branches than the default branch we are investigating if we have to do that manually or if the could be something added to our GitHub actions.

I said reading the issue tracker where there is nothing to indicate a pull request exists ~(https://issues.joomla.org/tracker/joomla-cms/46904) AND dont you need to merge #46835 for the automation to happen

AND dont you need to merge #46835 for the automation to happen

@brianteeman Definitely no! That PR only adapts our pull request template to add the right keyword for assigning the issue. If we add (or modify) that manually in existing PRs, which I have done e.g. for yours, it also works. That PR does not add that functionality, it is a GitHub standard. So if people already use e.g. "resolves xxx" or "fixes xxx" in their PR description, with "xxx" being the reference to the issue, it would work since ages.

P.S.: Currently the issue tracker is only useful for human testers to submit their test result, for maintainers or bug squad to set RTC or for automatically setting some labels on GitHub. Besides that it does not really serve much purpose and is a pain, so we (maintainers) want to get rid of it sooner or later. We are working on it to come to that direction.

Doesnt change what i said about the issue tracker. while it exists there is nothing there to tell people that a pr exists and my comment referencing the pr was 100% relevant and required.