Closed Adda0 closed 8 months ago
I personally prefer for keys to be missing from languages when not translated, as the error message help bring attention to missing translations.
The Translation.Get
method should prevent any crashes for missing keys. What situation(s) did you see that would cause a crash when lacking a translation?
I find it awkward when the inner error messages such as missing translation key leaks to the UI. The program feels broken and basically prevents users from using any other language than the language the developers develop the application in, as the application UI will feel unusable.
I saw the missing translation error messages in the UI, but I was not sure if the translation methods cover all the basis. If you think the application should not crash, then what you propose is an option, too.
Still, I think showing the English translation will make the UX much better when using non-English languages. It is up to you to decide what works best for you. I can update the other languages with English translations when the time comes, if you decide for this approach instead. If not, feel free to close this issue.
Looks like I already handled this situation, as Translation.Get
should use the default.json
when missing the key in the non-English selected language.
Are you seeing behavior that shows otherwise?
Aha. That is great. Then everything should be fine. I am not aware of any existing translation bugs to say otherwise. I will close this issue as completed, then.
When #148, #153, #154, and #155 are resolved, all non-English translations need to be updated to include (for now in English, I presume) the new and modified translation tags for all the new/modified text from the last several PRs (#143, #145, #147, #148, #150, #153, #154).
Otherwise, running the application in any non-English language will cause issues (no translation found errors) and might even crash.