Change translation resolution about i18next-gitbook HOT 18 CLOSED

I don't understand why you may need this?

Maybe try: const translation = i18next.exists('ns1:key1') ? t('ns1:key1') : t('ns2:key1')

from i18next-gitbook.

I'm using fallback for both, namespaces and language. So in case an EN translation is not found. I don't want it to switch to a DE translation. Instead, find an EN translation from another namespace.
Wouldn't t('ns1:key1') return a DE translation from namespace 1?

from i18next-gitbook.

if there is a de translation yes
But if you pass in the lng option in the exists call I think it could work.

But honestly I don't get why you do this at all. 🤷‍♂️

from i18next-gitbook.

Honestly, I‘m not a fan of the namespace fallback.

What is your use case?

from i18next-gitbook.

I use some language fallback as well as some namespace language. And the translation by default. check the en translation from common namespace, if it's not found, it switch to another language, de from common namespace. And I don't want that.
I want to check en in other namespaces( like custom) and only if it didn't find it en in other namespace. Only then pick other language (de) from common namespace.

from i18next-gitbook.

the question is. why you need that. why you have a key not in common en but in common de?

from i18next-gitbook.

why you want the key to fallback to the other namespace in en but not for de

from i18next-gitbook.

Because the user expects an en translation. So first I would check the en translations only than switch to another one.

from i18next-gitbook.

than again. why is the key not in common en?

from i18next-gitbook.

Maybe misspelled or was not added.

from i18next-gitbook.

so you just lucky search around in other namespaces and hope to find that key some where else?

thats not really a use case that is missing translation management.

a use case would be something like a generic error msg. or something similar.

from i18next-gitbook.

Yea, but I was hoping that the translation order can be configured.

from i18next-gitbook.

PR welcome

from i18next-gitbook.

Hi, I was just browsing i18next, since we just started using it for our app and we have a use case, which would be good if we can accomplish something similar to original request.
Use case is that we have general app translations (all the translations possible) and specific translations (only translations needed) per user company type. So, we should be looking for the translation in order like this:
en-custom
en-common
de-custom
de-common
Or maybe it is ok that this be accomplished by testing if the key exists in a given namespace as adrai suggested? Disadvantage is as I see it that then we need to test it with each key.

from i18next-gitbook.

There's also the possibility to use custom language.
i.e. de-x-custom which fallbacks to de and then en

from i18next-gitbook.

It would be nice to have this feature.

Honestly, I‘m not a fan of the namespace fallback.

What is your use case?

For example in our use case, we have modules with custom glossaries to reword concepts inside that module, and we store those keys as custom namespaces. Admins can modify these glosaries per language and we have a set of common keys per language because it's optional to do. So whenever you access this module, we would like to have yourLang-custom || yourLang-common before defaulting to the default language, because the rewording of the concept is only for that specific language.

from i18next-gitbook.

https://www.i18next.com/how-to/backend-fallback

from i18next-gitbook.

Just for the record, we ended up implementing our own t function in a custom HOC that uses i18next t from useTranslation in a certain way. We use it first but overriding the opts with fallbackLng as empty [] and a special defaultValue. If the translation obtained is that special value (or we can use i18next exists), we assume we have gone through all namespaces in that language and there is no translation, so then we just use i18next t normally without touching the opts so the fallbackLng set in the config is picked up.

Not the prettiest because I guess in the worst case scenario you are "double" translating, but it's working for our use case and we couldn't find a different approach at that moment.

from i18next-gitbook.