i18next: Wrong or missing key is not highlighted when there is a fallback
đ Bug Report
Wrong or missing key is not highlighted when there is a fallback.
To Reproduce
Expected behavior
In both cases Iâm referencing a key that doesnât exist, but in the first case I have a fallback, and the wrong key is not highlighted. In the second case, where i donât have a fallback, I get it highlighted.
Your Environment
- âi18nextâ: â^23.5.1â
- âreact-i18nextâ: â^13.2.2â
- âi18next-resources-for-tsâ: â^1.3.3â
i18next.d.ts
import Resources from './resources';
declare module 'i18next' {
interface CustomTypeOptions {
defaultNS: 'myfile';
resources: Resources;
}
}
Resources generated following this step
About this issue
- Original URL
- State: open
- Created 9 months ago
- Comments: 22 (10 by maintainers)
Extraneous options should still be possible. There might be other i18next plugins or postprocessors that needs this.
But an option to toggle the TS validation when defaultValue is used, would be a nice addition.
Itâs possible to make TS throw an error for extraneous options, I just never opened a PR for this because I wasnât sure if it was useful to anyone.
I can open a PR that adds a new option to change the behaviour. Is that preferred, or should we leave this as-is?
Just adding, as someone very new to this project, that @SaraRavasio point resonates with me. I would expect to be able to get flagged if a key is missing, even if fallback is provided. If this is via an option or something I can setup in my project once to get that behavior, this is fine enough if documented properly. I guess you donât want to break existing workflow and I get that, but probably this should be a sane default for newer projects (have it in the documentation or in your examples)
To add my pinch of salt, feel free to tell me this is another issue that needs to be filed, but interpolated keys should also fail if the options object is not provided at all (first line of the âwrongâ). We are implementing i18n + locize currently, and we currently have a rule to always include an object as second parameter, even if empty, to have peace of mind that TS would catch mistakes.
Interpolation in the default value (the 2&3 lines in the wrong) donât matter to us much, we have a rule to never get fallbacks (to keep TS checks). but if it could be correctly checked, we could get back to provide defaultValue.
And while on the subject, it also never consider count to be a missing key in option, even for plural keys, but thatâs a very nice to have compared to whatâs discussed here
Optional (or even required) parameters donât exist in vanilla javascript. So the compiler complaining (or not) when providing or missing function parameters is very much a âtype safety checkâ and purely from the âtypeâ point of view.
Regarding implementing this as an option I unfortunately lack the time to support. You might want to have a look at the option(s) I mentioned and how they are implemented. That might give you some pointers. Best of luck!
My point is essentially: If a default is provided, itâs not an error if no value exists. Thatâs the whole point of a default value: providing a fallback.
Just think of any function where you provide a default value for a parameter. You wouldnât expect typescript to complain if you donât provide one, when you use the function, right?
So to your point:
Yes, thatâs exactly what should happen, because it will show the default.
Remember: Key-checking isnât a miracle weapon that prevents you from doing stupid things. It only checks the default translation file. So for example if you only provide a key in the default lang and then forget to add it in other languages, only the closest fallback will be displayed. No error will be shown, even with strict key checking.
That being said, I agree that a point can be made to opt into strict key checking, which should be feasible with an option in
i18next.d.ts, similar to howallowObjectInHTMLChildrenworks.Wether or not this warrants the extra complexity in the code is for the maintainers to decide and likely depends on how many others also think that this is needed.
@janpaepke the default value is not only used when thereâs no key, but also when translations canât be loaded: instead of showing the translation keys, the default value is being displayed. That being said, I donât see the point of having a key validation to show us if a key is missing, if we just donât care about it if we have a default value, the two things are not really connected with each other. You have a very specific workflow in which you start by not having the keys and then adding them, but thatâs not usually the case. Also, what if someone by mistake removes a character from the key, because thereâs a default value i shouldnât be alerted that translations are using a wrong/missing key?
I think these behaviors should at least coexist, but i wouldnât completely remove the logic to check for the existence of the key and just bulk accept a random string.
Also, Iâm not sure why we wouldnât want a check for the exact variables to be passed, I would just assume that being the best type safety, but maybe iâm missing something here đ
Btw, Iâm basing this behavior also having seen how flutter is integrated with i18next.
Sorry, but Iâm not a TS expert. đŚ
Maybe @pedrodurek @janpaepke @marcalexiei @hussainahmad @jtbandes @henrikvolmer @JounQin @nicegamer7 can help?