Wrong i18n usage cause some unexpected TypeError

[backrunner]

💡 Summary

There's a weird behavior about I18n in /packages/frontend/src/scripts/i18n.ts
In getter tsx, when _DEV_ is false, it's cannot ensure that the type of the return value is consistent, it might be a string or function.
But in development mode, as all the values are wrapped by a Proxy, the type of the return value is always a Function.

IMO, the L180 should be result[k] = () => value; continue;.

There're already some wrong usages existed, as for the _accountMigration, some languages contain {n} expression, and some not, that will cause TypeError on the UI.

🥰 Expected Behavior

The type of the return value from I18n.tsx should be consistent.

🤬 Actual Behavior

Apply codes in __DEV__ to the releases, remove the old one, or modify the old one to make the type of the return value consistent.

📝 Steps to Reproduce

No response

💻 Frontend Environment

* Model and OS of the device(s): macOS, MBP Pro
* Browser: latest Chrome
* Server URL: pwp.space
* Misskey: 2024.3.1

🛰 Backend Environment (for server admin)

No response

Do you want to address this bug yourself?

• Yes, I will patch the bug myself and send a pull request

I'm not quite sure that should I patch the old code or just apply the code in DEV to release version, and remove the old one, we can discuss that then I can submit a patch if you guys are busy :D

[acid-chicken]

some languages contain {n} expression, and some not

Good catch!
The current logic implicitly assumes that the presence or absence of parameters is consistent across all languages, and indeed they should be.
However, there was no mechanism to check for these in the current localization process.
Rather than changing the application logic, this process should be revisited (e.g. CI check for locale parameters).

[dakkar]

https://activitypub.software/TransFem-org/Sharkey/-/merge_requests/493 should fix the "account migration" bits, at least