Hi @drmenzelit I'd appreciate it if you review my PR and leave the comments if any.
Thank you.

Joomla supports postgres so your code must do as well

obviously this only sorts categories in the front end. Presumably we would want to sort everything eg content, contacts etc and to do it in both the site and the admin.

@brianteeman I updated the code and PR comments for my Postgres updates.
Could you possibly check it at your convenience?
Thank you.

Thats a much better approach 💯

It needs a more architecture minded person than me to review it now.

One thing to note is that as far as I am aware when you use COLLATE you dont get to use the index which will be a performance issue

So or so it is a new feature and so the PR should be made for the 6.2-dev branch.

We will rebase it as soon as appropriate.

@mykh-hailo Please fix the code style errors reported here: https://github.com/joomla/joomla-cms/actions/runs/23177295572/job/67368807088?pr=47403 . Thanks in advance.

This pull request has been automatically rebased to 6.2-dev.

This pull request has conflicts, please resolve those before we can evaluate the pull request.

@richard67 I fixed the PHP code style issue but now I have memory issue on the check.
Can you help me to solve this problem?
And the conflicts are also solved, it is ready for another review.

Thank you.

@richard67 I fixed the PHP code style issue but now I have memory issue on the check. Can you help me to solve this problem? And the conflicts are also solved, it is ready for another review.

Thank you.

@mykh-hailo What memory issues? I only can see that there a<re still code style issues, see the log here: https://github.com/joomla/joomla-cms/actions/runs/23193887694/job/67397075835?pr=47403 . They are all related to alphabetical ordering of use statements.

@richard67 @chmst
Thank you for your quick review and kind explanation.
I fixed the PHP code style and made another updates.
I'd appreciate it if you check it again at your convenience.
Thank you again.

I have tested this item 🔴 unsuccessfully on 97a35a6

Partly successful (backend article and category Title ordering OK) and partly unsuccessful (frontend category article list/blog and category list NO CHANGE)

Backend list reorder correctly with the patch when selecting Title ASC or DESC, similar for backend categories.

With the patch ØÆÅ are sorted correctly, and also second letter (æøå) ordering now is correct too.

Frontend there is no change in sorting with the patch applied.

@ot2sen Thank you for comments.
I checked on my end and found out everything works find on my end.
Wondering if you set the user site language to Danish.

@mykh-hailo Yes, site and admin language default set to da-DK.
Tested on nightly:

Joomla! 6.2.0-alpha1-dev Development [ TBD ] 26-May-2026 18:00 UTC
PHP 8.3.24, mysql 8.0.31, utf8mb4_general_ci, utf8mb4_0900_ai_ci

Front ordering failed/no change.

Backend article list and category list works OK with patch applied. Ordering corrected for da-DK :)

@ot2sen Thank you for the feedback.
Can you try to press Titel to sort by Title?
The default sort item is not Title, thus we have to press the header to sort by title?
If you want, I can update the default sort item to title.

@mykh-hailo Manually clicking the Titel to reorder do make the ordering correct. Nice :)

Problem is that it should pick up the settings from the menu item and be correctly orderer without clicking.
Same for category blog. It doesn´t order the category blog articles correctly either. Even when menu settings Category order = Title alfa and Article order = Title alfa, are set.

Category blog wrong ordering:

@ot2sen I updated the code for your comments.
I always appreciate your quick feedback.
Thank you.

I have tested this item ✅ successfully on e8f612f

Site article list and site category blog now correctly alphasort with the latest fix for menu settings. Also tested that for example article ordering setting still work as should. It did. Well done. :)

The site Titel alphasorting now looks good.

@ot2sen Thank you for your kind review and effort.
I'd appreciate it if you can give me the ETA for the merge please.

@mykh-hailo

I'd appreciate it if you can give me the ETA for the merge please.

The PR needs another successful human test. It will be checked by maintainers and the release managers for Joomla 6.2 will merge it, if all is ok. It can take some time. Here you can follow the scheduled times for Joomla 6.2: https://developer.joomla.org/roadmap.html#r-1024

the purpose of $db->escape() is to sanitize the values before they are inserted into the SQL query, primarily to help prevent SQL injection. You have removed every instance of this - why?

the purpose of $db->escape() is to sanitize the values before they are inserted into the SQL query, primarily to help prevent SQL injection. You have removed every instance of this - why?

As far as I could see that is done inside that new method now.

the purpose of $db->escape() is to sanitize the values before they are inserted into the SQL query, primarily to help prevent SQL injection. You have removed every instance of this - why?

As far as I could see that is done inside that new method now.

You get the correct point.

Code Style Check is failing: https://github.com/joomla/joomla-cms/actions/runs/23335597398/job/67882997663?pr=47403
Fixed.

I‘ve restored @ot2sen 's test result in the issue tracker as the commit which invalidated the test counter was just a code style change.

It should also be tested with 3rd party extensions which do not specify a character set and collation in their create table statements in their installation SQL so the database default is used and which do joins with core database tables. Such could cause an invalid mix of collations. Unfortunately I don’t have an example extension for that. I remember something but that was for Joomla 3.

I see admin application and site application but does it also need API application?

@richard67

One thing to note is that as far as I am aware when you use COLLATE you dont get to use the index which will be a performance issue

The idea seems valid, but implementation not very.

Such changes need to be part of Database layer.
Not as a static helpers across the code base.

@richard67

One thing to note is that as far as I am aware when you use COLLATE you dont get to use the index which will be a performance issue

Hmm, yes, that could be another issue on large sites e.g. with many articles.

@richard67 which must mean that this is something optionaly enabled with a warning that it would impact performance

@ot2sen did you check what happens with search?

@Fedik yes a valid idea indeed. The how-to is for you folks to decide on. From an end user perspective it is great to see someone actually doing it in 2026 after 10 years of lack/bug in the core internalization part of the code. Any language matters :)
@richard67 @brianteeman True. A switch to activate such improved i18n for extended charsets could be a choise for the site admin, with a select option from the installed languages.
@brianteeman Search: yes, basic tests. Worked before and after in the small testdata set I had. Didn´t find anything out of order so to say :)

@brianteeman @richard67 @Fedik @ot2sen
Thank you for the updates and comments.
So what should I improve or consider on the next update?

@brianteeman Could you possibly share any updates or advice on this PR please?

#47403 (comment)