[Bug]: Switching translations causes error on program start

[DelphicVoiceAddragh]

Checklist

• I am using an up-to-date version.
• I have read the documentation.
• I have searched existing issues.

TagStudio Version

Alpha 9.5.0

Operating System & Version

Windows 11 Home 23H2

Description

I was testing languages for reporting a different bug, but when I switched to one of them (German, I think. It's near the top of the list, anyhow), the program refuses to open and throws this error.

I also tried deleting TagStudio and re-extracting it to attempt to reproduce this, but the error seems to persist across installs.

Expected Behavior

The program starts normally (and bugs to not persist between installs).

Steps to Reproduce

Either:

1. Switch to affected language (again, I believe it's German)
2. Restart TagStudio
   or rapidly switch languages, restarting the program each time, and it'll happen at some point.

For obvious reasons, I can't test this at the moment. If I can somehow get TagStudio working again, I'll update this issue with more info (and make the other report I mentioned).

Logs

No response

[SkeleyM]

Hi i was able to recreate this,
the language configuration is stored here in if you'd like to fix your language and use tagstudio:
"C:\Users\{User}\AppData\Roaming\TagStudio\TagStudio.ini"

open the file (TagStudio.ini) and change the language=de to one that seems to not crash like language=en (english)

other languages dont seem to fully crash on start but cause other issues.

(for contributors)
This seems to stem from translations having their format key names changed, however those changed were not reflected in all translations which results in a crash.

this issue seems to exist in more than one translation and at least more than one translation keys

offending code:
499: Translations["menu.delete_selected_files_ambiguous"].format(trash_term=trash_term())
English:
"menu.delete_selected_files_ambiguous": "Move File(s) to {trash_term}",
German:
"menu.delete_selected_files_ambiguous": "Datei(en) nach {trash_item} verschieben", (outdated 'trash_item' instead of 'trash_term')

[CyanVoxel]

(for contributors)
This seems to stem from translations having their format key names changed, however those changed were not reflected in all translations which results in a crash.

I don't believe the name "trash_item" was ever used, and is instead just a typo of "trash_term" inside of de.json. Good catch though!

I suppose this is a two-part issue then - the de.json file should be repaired (edit: already complete in #826), and future errors from translation files shouldn't have the ability to crash the program

[CyanVoxel]

I started work wrapping each new case of .format() in try/except blocks to catch KeyErrors, however I realized when hitting some lambdas that this is not always possible to catch - plus, having a translate_formatted() method like the one used prior to #817 would be a much easier way to catch these errors.

I think selectively reverting some of the changes in #817 to restore the use of the translate_formatted() method while adding error handling inside that method would be the best approach here.

[Computerdores]

I started work wrapping each new case of .format() in try/except blocks to catch KeyErrors, however I realized when hitting some lambdas that this is not always possible to catch - plus, having a translate_formatted() method like the one used prior to #817 would be a much easier way to catch these errors.

I think selectively reverting some of the changes in #817 to restore the use of the translate_formatted() method while adding error handling inside that method would be the best approach here.

I do wonder if that isn't just combating symptoms.
Because this error occurs when a format strings placeholder can't be filled because the value isn't supplied. So shouldn't we be supplying the value instead of wrapping the entire thing in a try catch?

[CyanVoxel]

I do wonder if that isn't just combating symptoms.
Because this error occurs when a format strings placeholder can't be filled because the value isn't supplied. So shouldn't we be supplying the value instead of wrapping the entire thing in a try catch?

The issue was caused because an incorrect value name was submitted as part of an updated translation file, which when ran in the program caused a hard crash due to a KeyError when trying to format that string(s). This is a very easy issue to create, and all it takes is a small mistake in the translation files that can be created by anyone submitting translations, and it's something that can be incredibly difficult to visually catch as well as test for. In a perfect world, everyone will only ever use valid formatting keyword arguments, but this is far from a perfect world scenario.

Catching the errors here will have no downside by not hiding translation key issues, while having the upside of not letting syntax errors in public translation files cause the program to completely crash and potentially lock people out without manually modifying their .ini file.