IBX-11127: Datepicker is always in english despite BO language change

[Sztig]

🎫 Issue	IBX-11127

Description:

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

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[GrabowskiM]

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...

[GrabowskiM]

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...

Discussed in private - changing order in admin-ui-layout didn't work, therefore I'll approve current solution. It's not perfect (as we rely on size of that file) but it's much smaller change than changing structure of DatePicker, enforcing custom calls to localize with each call to flatpickr etc.