Can you change this to "FSRS can adapt to your memory well"? t better conveys that the health check is NOT about the current parameters. Dae approved this change, btw.

Also, now that Evaluate is gone, I think it makes sense to put "Optimize Current Preset" on the same level as "Optimize All Presets", not one above the other.

I'm worried that inlining the optimize all presets button would increase the rate of miss-clicks.

But right now it's ugly 😭

It would also make sense to de-emphasize the button that users should click only secondarily, like this:

Were the "Health Check:" prefixes discussed somewhere? They feel a bit redundant to me, but I won't hold up the PR for them. The misaligned simulator button would also be nice to fix in a follow-up :-)

Thanks as always for your contributions Luc, and to everyone else as well.

Is there a specific reason for separating "{ $text } (slow)" into its own string, while pulling back the original string via a parameter?

I'm asking because this kind of word puzzles are extremely difficult for translators, even more if there are no comments clarifying what is happening.

(If this is just a sort of refactoring, I would propose to roll back the part that introduced deck-config-slow-suffix before this gets into Pontoon.)

Doing it this way gives the translators latitude to append the text in a natural way, and allows us to add a slow tag to other things in the future without requiring another/multiple translations. I do appreciate that variable substitution has a level of complexity, and should have thought to suggest we at least add a comment to it.

Were the "Health Check:" prefixes discussed somewhere?

Nope, that was all me. I thought that there should be something to more directly associate the resulting message with the setting (in case it was left on by accident) and also distinguish it from the "Your parameters are currently optimal" which might otherwise be seen as part of the health check.

Makes sense, and not something I feel particularly strong about. Thanks for clarifying.

Doing it this way gives the translators latitude to append the text in a natural way, and allows us to add a slow tag to other things in the future without requiring another/multiple translations.

I'm not entirely convinced.

Currently, we have two strings (deck-config-slow-suffix and deck-config-health-check) instead of just one (deck-config-health-check) as before. That creates more work for translators. It's also more complex due to the wordplay involved, and translators are given less flexibility — in some languages, an English-style "(slow)" suffix may not be ideal or natural.

Furthermore, deck-config-health-check has already been translated into 10 locales at the time of writing this comment. Translators will not be notified that the "(slow)" part has been removed from it. As a result, it's quite possible that they will happily translate deck-config-slow-suffix but leave deck-config-health-check unchanged, leading to translations like "Check health when optimizing (slow) (slow)". Unless they're actively monitoring this thread — which seems unlikely — this inconsistency could easily slip in.

So for now, the situation is more complicated than before. And in the future? Will this approach actually reduce translators' workload? Even if we introduce a new slow feature later on, we could simply call it "Our new feature (slow)". There’d be no need for deck-config-slow-suffix. The only real benefit I can imagine is if we have an already-translated string that we now want to label as "slow" — then deck-config-slow-suffix would spare us from requiring a retranslation. But that seems rather unlikely, doesn’t it?

It's important to recognize that translations are not code — they follow entirely different principles. While concepts like "Don't repeat yourself" are valuable in programming, they can be counterproductive when applied to natural language. And while translators often work close to technology, they aren't necessarily programmers.