github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-05-06 07:01:45 -05:00
Code Issues 1.5k Packages Projects Releases 54 Wiki Activity

[GH-ISSUE #3449] [Bug]: String normalization doesn't properly handle Polish "ł" #8364

New Issue
Closed
opened 2026-04-10 18:33:51 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-04-10 18:33:51 -05:00
Owner
Copy Link

Originally created by @EvidentlyCube on GitHub (Sep 15, 2024).
Original GitHub issue: https://github.com/actualbudget/actual/issues/3449

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:
image

But not l at the end:
image

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

Originally created by @EvidentlyCube on GitHub (Sep 15, 2024). Original GitHub issue: https://github.com/actualbudget/actual/issues/3449 ### Verified issue does not already exist? - [X] I have searched and found no existing issue - [X] 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:** ![image](https://github.com/user-attachments/assets/c2a9fcba-3a66-45e5-8bfa-acd097d727bd) **But not `l` at the end:** ![image](https://github.com/user-attachments/assets/6b3c642c-4a87-442f-bda2-8aea2ad7d3f3) 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](https://en.wikipedia.org/wiki/%C3%9C)). A solution similar to [this SO answer](https://stackoverflow.com/questions/75331623/normalize-special-letter-char-from-various-foreigner-languages) 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
GiteaMirror added the good first issuebug labels 2026-04-10 18:33:51 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
AI generated
API
bank sync
budgeting
bug
can’t replicate
dependencies
docker
documentation
electron
experimental feature
feature
feedback
goal templates
good first issue
help wanted
importers
maintenance
needs info
needs testing
needs triage
needs votes
openid
payees
pull-request
Mirrored from GitHub Pull Request
 regression
reports
responsive
rules
schedules
server
✨ merged
split transactions
tech debt
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No Label bug good first issue
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#8364
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?