Provide an i18next.availableLanguages variable

[sh-pq]

Following on from this question I asked, I've kept digging and I am pretty sure this feature doesn't seem to actually exist.

I suggest adding a new value to the i18next API: i18next.availableLanguages. This will list the current range of languages for which resources are loaded, such that calling i18next.changeLanguage(code) with a code from that list will produce a translation using a resource file for that language.

Consider the following scenario in which I initialise my application:

i18next.init({
    fallbackLng: "en",
    resources: {
      en: { ... },
      de: { ... },
      tlh: { ... },
    },

This setup (with no supportedLngs attribute) now supports switching to any language that might be available, but the only available languages are en, de, and tlh.

During runtime I download some updates from the server for new language support:

i18next.addResourceBundle("ko", "translations", { ... });
i18next.addResourceBundle("jp", "translations", { ... });
i18next.addResourceBundle("it", "translations", { ... });
i18next.addResourceBundle("es", "translations", { ... });
i18next.addResourceBundle("pt", "translations", { ... });
i18next.removeResourceBundle("tlh");

The list of available languages is now ["en", "de", "ko", "jp", "it", "es", "pt"]. If I were to present a language switcher to the user, I would want to provide that exact list of options. However, there isn't a trivial way to ask i18next for this list.

If I want to have this information I have to separately track what I've added and removed, but that is a secondary source of truth and may or may not reflect what is actually made available by i18next right this moment. I want to consult i18next itself as the source of truth on what it can do here.

The closest equivalent I've found so far is to look at the keys on the resourceStore's data:

const supportedLanguages = Object.keys(i18n.services.resourceStore.data);

This seems hacky though and not like the right way to do this. Hence more directly providing this information via the i18next instance as i18next.availableLanguages.

[jamuhl]

please read the docs https://www.i18next.com/overview/configuration-options#languages-namespaces-resources -> what supportedLngs is used for (not what is loaded - but what is allowed to load <-- you provide the complete list)...

https://www.i18next.com/overview/api#hasresourcebundle <- check if there is data for lng, ns

https://github.com/i18next/i18next/blob/master/src/ResourceStore.js#L158 <- check lng has some data

accessing i18next.services.resourceStore.data should give you an object with all stuff currently loaded const lngs = Object.keys(i18next.services.resourceStore.data) (just blindly created code - but should work)

[sh-pq]

Ok, I see — supportedLngs is quite literally an allowlist and isn't something I necessarily need to provide unless I want to restrict the list of languages. If I provide it and load a new language, I am still not allowed to switch to that language because it is not in the original list.

changing language to "es"
i18next::languageUtils: rejecting language code not found in supportedLngs: es

However, if I omit the supportedLngs value at setup, all languages are allowed for me to switch to provided I have a translation for them. That returns us to the original issue: there is not a direct way to ask i18next for the languages currently loaded and available.

That is, except by elaborating on the keys for the resourceStore data object. I tried that in my original post (it does work) but it seems hacky and not like it should be the proper way to do it. I guess right now it is in fact the only & proper way to do it? But it seems like quite an important piece of information to ask of i18next and quite a hacky and indirect way to get the answer.

So as to not overlap with supportedLngs which performs a different job, I'm renaming the property in this request from i18next.supportedLanguages to i18next.availableLanguages.

[jamuhl]

using i18next with some backend -> you never know what languages are available...you only know what was loaded based on detected user language...

so if you need something like available languages...you must provide that list...we can't provide it...

cause of this...renaming makes no sense...as it is not available...

[sh-pq]

This is a frontend in React Native. We do know what's available since it's available by looking at the resourceStore, don't we?

I'm definitely not asking for a rename, I'm raising that i18next does seem to provide a roundabout way to find out what languages are available to switch to that have translations, but it does not provide a direct way to ask for that information. The list does appear to be available and i18next does appear to provide it, just indirectly.

Like, in the scenario I start off with resources for 4 languages and add a 5th — I think i18next should support a property that tells me a list of languages that now have translations, including that 5th value. It has that information, it could tell me that information, and it seems like an obvious thing to ask i18next for.

In case my last comment confused things, I am not asking to rename i18next.supportedLngs, I just changed the name I was asking for in my request to avoid conflict with supportedLngs because this would be a fundamentally different property. I am asking for a new property that does something completely separate—which is provide a list of languages for which resources are currently loaded and available.

[jamuhl]

if it's react-native and you seem not to load the translations from a server...there is no need to ask i18next for the locales to show in a language switcher...you have that information upfront and can hold it anywhere...