I'll think about it. As they also represent physical folder names, I prefer not to translate them, but I might do like Window does and present a translated name (although it's more confusing, right?)

People who hate English can delete them and set up their own project groups using any names they please.

b19 now available.
Changes:

• Improved rendering speed of recent projects group (it's now cached)
• Lowered CPU usage of project monitor (code that looks for changes to projects)
• Fixed ordering bug for recent projects list

Someone should start a GoFundMe site to get you some new gear. On both my aging Windows desktop (Intel i7 and SSD drive, but from 2018) and my shiny new M2 Macbook Air, jAlbum starts up in under 4s.

What matters isn't how the project groups are presented visually. What matters is where they reside on the hard disk. The "Tests" folder shows up next to "My Albums" visually (for convenience), but is actually located under "My Albums", hence it can be deleted instead of just unlisted.

I envision that the vast majority of those who use project groups will prefer a flat structure (one level of groups), it's however clever to physically store groups under a common root ("My Albums" for backup/restore purposes for instance. That's why "Samples", "Tests" and "Favorites" show up NEXT to "My Albums" but are physically stored UNDER it.

I anticipate that a minority will want to create deeper physical AND visual structures. They can use the sub group concept for that, for instance creating a "Clients" group, and populate it with sub groups for each client.

I agree. It will be interesting, and perhaps a little horrifying, to see the limits to which some of the resident "archivists" will push this mechanism. Will it scale up to petabyte repositories?