Skip to content

Conversation

@Sztig
Copy link
Contributor

@Sztig Sztig commented Dec 23, 2025

🎫 Issue IBX-11127

Description:

Flatpickr translation script was being included too late in the chain so I have moved it before the layout-js.

@Sztig Sztig requested a review from a team December 23, 2025 14:02
@ibexa-workflow-automation-1 ibexa-workflow-automation-1 bot requested review from GrabowskiM, OstafinL, albozek, alekmick, dew326 and tischsoic and removed request for a team December 23, 2025 14:02
@sonarqubecloud
Copy link

@mateuszdebinski mateuszdebinski added Bug Something isn't working Ready for review labels Dec 29, 2025
@GrabowskiM
Copy link
Contributor

I'm not sure if it's correct solution for this problem. For one it can be some BC change, as if someone made custom layout and includes there admin-ui-layout he will not have this flatpickr file there. But what mainly concerns me, is that with this solution it's kind of race condition.

If I understand correctly, the problem is that we initialize flatpickr instances in code before calling localize method so existing ones have old language, as they can't change their language live. And by putting it to totally new (and much lighter) entry browsers load it much faster than admin-ui-layout therefore executes it before any initialization happens.
If that's the case, maybe we could just put this file at the begininng of admin-ui-layout, therefore it would be executed before anything else?

In theory we use flatpickr only internally, inside our DateTimePicker class so this could be set there as well, but that's risky, as if someone uses it out-of-the-box he would have to call localize by himself...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Bug Something isn't working Ready for review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants