[Bug]: String normalization doesn't properly handle Polish "ł"

[EvidentlyCube]

Verified issue does not already exist?

• I have searched and found no existing issue
• I will be providing steps how to reproduce the bug (in most cases this will also mean uploading a demo budget file)

What happened?

String normalization while filtering allows Actual to ignore diacritic characters. If I have a category Pączek I can find it when adding a transaction by typing either pą or pa which improves usability. This works for almost all characters in Polish language with the exception of ł:

Works with ł at the end:

But not l at the end:

As a Polish native I can confirm that being able to use l to find ł (in this context) an expected behavior.

---

The reason this doesn't work out of the box is because string normalization can only remove diacritics from Latin characters and ł (as well as its upper case variant) are a distinct character rather than latin+diacritics. A few other languages will likely have similar issues with their characters like German ß=ss or Norwegian ø=o. It gets even more problematic for cases like ü which in some languages it can be u and in others ue (wiki source).

A solution similar to this SO answer could be used but it doesn't help with u/ue. An alternative would be to have a dedicated compareStrings() function which checks both "romanizations" but it greatly increases the computational cost of comparison and with enough variations it becomes unfeasible to check all combinations.

Where are you hosting Actual?

Locally via Yarn

What browsers are you seeing the problem on?

Firefox

Operating System

Linux