Bug 39001

Summary: Language list is displayed in wrong order (getLanguages doesn't sort it, the order is UB)
Product: Koha Reporter: Michał <schodkowy.omegi-0r>
Component: OPACAssignee: Owen Leonard <oleonard>
Status: NEW --- QA Contact: Testopia <testopia>
Severity: trivial    
Priority: P5 - low CC: dcook, jonathan.druart, martin.renvoize
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38646
Change sponsored?: --- Patch complexity: Trivial patch
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:

Description Michał 2025-01-30 10:12:16 UTC
Caught by unit tests added in Bug 38646, but it's not a regression of that bug. It seems that the list of languages from getLanguages is not ordered in any way, instead it relies on the implementation detail of the database server in terms of the order it returns things in. Indeed even before that bug was merged, in Koha 24.11 and 24.05, one can observe in OPAC -> Advanced search -> Language, that the order of languages is indeed a bit wrong (for example: amh, grc, ara -- Old Greek (grk) has nothing starting with "a", so it has no business being this high in the list).

The solution in principle is simple, just order the returned language list (TBD what to order it by: by language code, by English name, by effective final display name????). It's also TBD whether getLanguages should sort it itself, or whether places that display languages, such as `/cgi-bin/koha/opac-search.pl`, should actually be doing the ordering in preferred fashion.

In any case, the tests at t/db_dependent/Languages.t fail due to wrong order after some MariaDB update, so current order is undefined behavior.

Also if we select to change the behavior of getLanguages, then it'll be trickier to backport it, since dependent Bug 38646 is enhancement due to slight change of behavior. But the backporter could easily adjust the SQL query there to make the lines "THEN CONCAT(" be selected with removing the conditional, so that the language list is always appended in parentheses (old behavior).
Comment 1 Michał 2025-01-30 10:14:19 UTC
Also wasn't sure whether to mark it as OPAC or I18N category. Technically the user-facing display bug is in OPAC, even though also unit test regressed after MariaDB update due to the UB. Welp.
Comment 2 David Cook 2025-01-30 22:29:44 UTC
I was going to say that sorting the @languages_list at the end of getLanguages() would be the easiest solution, but that wouldn't be translation friendly...

...but it looks like we just use the description straight from the database, so that's fine. 

I don't recall if sort() can handle UTF-8 or not. I think it should. But if not it might be necessary to use something like Unicode::Collate's sort()
Comment 3 David Cook 2025-01-30 23:01:19 UTC
Or do we sort by code? 

Using Unicode::Collate might be useful with the description because that would use whatever the default is used in the Unicode Collation Algorithms...

I wonder if Greek speakers would expect to find Greek at the end of the list or in the Es... 

This could be another case where Unicode::Collate::Locale could be useful although it runs into issues of installed locales... see bug 36947