Skip to content

fix(home): show built-in preset names in the current language (#744) - #765

Merged
KnifeLemon merged 1 commit into
mainfrom
fix/744-history-name-language
Oct 29, 2026
Merged

KnifeLemon merged 1 commit into
mainfrom
fix/744-history-name-language

Conversation

@KnifeLemon

Copy link
Copy Markdown
Owner

Fixes #744.

Home's recent conversions kept the preset name as the text shown when the job ran, so after switching languages a row still read e.g. 长图 instead of "Long image".

  • HistoryEntry.PresetNameKey: the built-in preset's name key, recorded only when the job showed exactly that key's translation (no user name, same text). Callers that pass another label (Spreadsheet Print Studio, a group's ring name) keep today's behaviour.
  • HistoryItemViewModel shows the key in the current language; the user's own names, entries from before and a key that no longer exists keep the saved text.
  • Search matches the shown name and the saved one.

Home is rebuilt on a language change, so nothing else is needed.

How was it tested?

  • dotnet test (RecentConversionTests, FailedFilesTests): new A_built_in_preset_name_follows_the_language_filee_is_in_now
  • dotnet format whitespace --verify-no-changes on the changed files

🤖 Generated with Claude Code

)

History kept the preset's name as text, so a conversion made while Filee was
in Chinese still read 长图 after switching to English. An entry now also
keeps the built-in preset's name key when the job showed its translated
name, and Home shows that key in the current language. The user's own names
and older entries keep the saved text; search matches both.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@github-actions github-actions Bot added the bug Something isn't working label Oct 29, 2026
@KnifeLemon
KnifeLemon merged commit 65a2737 into main Oct 29, 2026
20 of 21 checks passed
Marouane-elfadli pushed a commit to Marouane-elfadli/Filee that referenced this pull request Oct 29, 2026
A_program_that_keeps_reporting_runs_well_past_the_stall_limit touched every
50 ms against a 300 ms limit and failed several times today when a loaded
runner delayed one wait past 300 ms (KnifeLemon#759, KnifeLemon#765, KnifeLemon#766). The limit is now 1 s
and the fake program reports for 3 s, still three times the limit.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Feature]: 改善功能

1 participant