small addition to section about key fallback

[steevhise]

key fallback section failed to mention need for one more config option.

[jamuhl]

only needed if do not allow empty string as valid value - the pure inexistense of that key would correctly fallback to key. So adding this flag is just about empty string is a valid value or not - nothing todo directly with fallback to key.

[steevhise]

Ok, maybe I have a different understanding of what "fallback" means. To me, the idea of fallback is that the text string in question would display as something even if there were no translation for it in the requested language - regardless of whether the key is nonexistent or whether there's no value for an existing key, i still want to "fall back" to something besides an empty string. It's a stretch to even think of a use case where i'd want to return just a blank. I guess it's possible that in some language one would want to translate some fragment of a phrase as nothing, but this seems pretty rare to occur. I think there should at least be SOME mention on the Fallback docs page of the relevance and possible utility of the returnEmptyString setting. I'm not dumb but I spent days trying to make it work before i realized this. I'm sure others have had similar problems.

[jamuhl]

Nothing against a PR mentioning it somewhere just this setting is not needed here:

if you got JSON:

{ "key": "" }

you might want that empty string as valid --> shows t('key') ->

---

if you got JSON:

{  }

fallback to key --> shows t('key') -> key

[steevhise]

well that's my point above, I don't see that you'd often want to do that. when, realistically, would you want a blank result? In my experience with i18n, the problem with a missing translation is usually not that there's no key, but that you have not yet translated that string. most of the time, it's clear to the developer what displayed text needs to be translated, so the key is there in the resource. but there's a turnaround time to getting it translated, and so it's very likely that there will be missing values for existing keys, which you wouldn't want to be blank, you'd want to fallback to the original language,etc. but, whatever. i'll change the wording in my PR.

[jamuhl]

it already fallbacks to the fallbackLng defined -> what you're looking at is a fallback where the key acts as fallback language.

If there is something i learned in doing i18next over 7 years -> there is nothing like "in my experience = someone elses experience" --- everyone does it slightly different and has different preferences. Thats why there are more i18n frameworks out there than UI frameworks - i18n modules are the new "hello world" 😂.

[steevhise]

sure, everyone does it differently and that's why it's worthwhile to document a different way than how you're suggesting. :)

[jamuhl]

In addition to the above, if you want missing values to fallback to the key and not just a blank, you also need this setting

But this is not true -> It is only the case if you got the key existing in the JSON with empty string (missing values per definition are keys not existing in your JSON but in your code)

[steevhise]

what i mean by "original language" is the case where code was developed in a certain language and then i18n is being added later. the key IS the "original" text. which is why key fallback is needed. I personally don't think it's any easier to use keys that ARE NOT the actual text. it makes the code harder to understand and to edit displayed text if you have to constantly refer to your translation file whenever someone wants text changed. so key fallback, to me, is easier and better. but of course I agree, not everyone sees things that way.

[steevhise]

(missing values per definition are keys not existing in your JSON but in your code)

not true, necessarily. I use a code parser to generate json translation files automatically from the code. So at first ALL keys will be missing values, til translation happens.

[jamuhl]

So than i would say it must be:

In addition to the above, if you want missing values to fallback to the key in cases where the keys (eg. got extracted by a code parser) exist in your JSON translation file with empty string as value, you also need this setting

[jamuhl]

thank you for your patience...and the PR 👍