With a new php version there are some changes in the case mapping include ß (reference T319432)

Not sure if there should be visible effects right now or not.

wgCategoryCollation is set to "uppercase", so for ß the new uppercase SS could be in use.
Sortkeys are stored in the database, only new sortkeys generated after a edit are changed in the database, which does not give a stable sort order until everything is migrated.

Of course, there are visible effects. Without them we haven't noticed this change in sortkey generation.

So how can we request a migration for all sortkeys? We had the same situation with other letters, when PHP was updated from PHP 6 to PHP 7. We opened a bug report T251698, but nothing happend.

A migration of sortkeys should always be done, if a software, which has an influence on the generation of the keys, changes.

What we can do is a request for configuration change to set wgCategoryCollation to "uca-default".
Then script "maintenance/updateCollation.php" has to be run.
After this is done, we can request to set wgCategoryCollation back to "uppercase".
Then script "maintenance/updateCollation.php" has to be run again.
After that all our sortkeys should be up to date.

German Wikipedia is using ASCII codepoints like !#,:* and more for special effects.

If we would migrate to UCA many deliberate groupings would pass away.

We do provide explicit sortkeys for good reasons, also for umlauts and ß.

In T323868#9136829, @PerfektesChaos wrote:

German Wikipedia is using ASCII codepoints like !#,:* and more for special effects.

If we would migrate to UCA many deliberate groupings would pass away.

This is not the case, different symbols are still sorted separately with UCA collations. Example: https://pl.wikipedia.org/wiki/Kategoria:Socjologia (their order might be different though)

Switching German Wikipedia to an UCA collation was rejected a few years ago for reasons that aren't clear to me (T128806), so if someone wanted to propose that again, you'd probably need to have a new discussion about it.

Anyway, I think this task it not about German Wikipedia.

In T323868#8440845, @Formatierer wrote:

A migration of sortkeys should always be done, if a software, which has an influence on the generation of the keys, changes.

That's true, and we have a fairly routine process for doing this on wikis using UCA collations (here's an example from 2020: T264991), but it seems that either we overlooked that the 'uppercase' collations are also affected by some software upgrades, or someone decided that the changes are rare and small enough that it's not worth performing the migration on all wikis (it's a relatively slow and resource-intensive process). It seems to me that the ß change is pretty significant, though.

What we can do is a request for configuration change to set wgCategoryCollation to "uca-default".
Then script "maintenance/updateCollation.php" has to be run.
After this is done, we can request to set wgCategoryCollation back to "uppercase".
Then script "maintenance/updateCollation.php" has to be run again.
After that all our sortkeys should be up to date.

Correct, but this can be done in a simpler way – we can run maintenance/updateCollation.php --force to recompute the sortkeys without changing the configuration back-and-forth.

We can follow the process at https://meta.wikimedia.org/wiki/Requesting_wiki_configuration_changes. This seems like an uncontroversial change, so I don't think you need to hold a discussion about this. I could have the maintenance script started next week.

So far it looks like this should be done for German Wiktionary and for Commons. Should we perform the migration on any other German-language or multilingual wikis?

It has been refused since the resulting order is not the sequence which the community does need for thematic arrangement. It goes for names only and does not take into account deliberately distinguished structures based upon ASCII codes.

The request made above was to turn (all wikis, but at least German WP) to UCA default, which would break many applications.

The proposal has been evaluated, and it turned out that for more than 100.000 pages new individual sortkeys for non-name but ASCII encoded keys will need to be attached, and there is nobody who can create any algorithmic procedure for this. Furthermore a lot of desired sequences cannot be achieved in UCA; no solutions were found yet.

The proposal implies that all sortkeys are human language names of things only, but the sortkeys are used in German WP also for structural elements based upon deliberately chosen ASCII codes.

Probably it might work for German Wiktionary (I am not involved there), but it will definitely break German Wikipedia special article categories and systems out of article space.

Some rows are affected:

MariaDB [commonswiki_p]> select count(*) from categorylinks where cl_sortkey like '%ß%';
+----------+
| count(*) |
+----------+
|  5726636 |
+----------+
1 row in set (7 min 8.384 sec)

MariaDB [dewiki_p]> select count(*) from categorylinks where cl_sortkey like '%ß%';
+----------+
| count(*) |
+----------+
|   355433 |
+----------+
1 row in set (17.516 sec)

MariaDB [dewiktionary_p]> select count(*) from categorylinks where cl_sortkey like '%ß%';
+----------+
| count(*) |
+----------+
|   152100 |
+----------+
1 row in set (7.981 sec)

We changed a template (CH&LI) which was present in all pages containing an ß in german wiktionary, so that all related sortkeys were updated.

select count(*) from categorylinks where cl_sortkey like '%ß%';
Executed in 8.94 seconds as of Sat, 24 Feb 2024 10:47:04 UTC.
Resultset (0 rows)

So german wiktionary sortkeys are ß-free now.

Because someone asked me, a last notice: I think now, the problem was solved before by some repair-script. But it was forgotten to mention this here. Sortkeys of dewiki, enwiktionary and frwiktionary except commons are also ß-free now.

Please don't forget Commons! It's important because if I have 50 or 100 subcategories for a street name, I want to know at one glance whether there is a category for a particular house number or not.