React-i18next: Give alternate name to NamespacesConsumer

[chillitom]

Could an alternative name be given to NamespacesConsumer, this sounds very generic and doesn't really convey what it will be used for. WithT or WithTrans or something similar perhaps?

[jamuhl]

there is already the withNamespaces (HOC). NamespacesConsumer has same signature as the new context api -> being a render prop...so i guess Consuming Namespaces is not so bad. WithT is not really correct -> as the main purpose of this Component is not just passing t down (that we could have simpler) -> it handles loading of namespaces and rerendering on changes to lng, translations

[chillitom]

It's good to have that consistency but perhaps withNamespaces could also be aliased to something that reflects the intention of the developer that will be using this API, their intent is to access internationalisation features, they are already likely to have many namespaces of their own (throughout their code, modules, domain and data). Even WithI18nNamespaces would be add some clarity though it is quite verbose.

[jamuhl]

namespace is the term in i18next for multiple translation files...

i will keep this open....if more devs come up with naming demands we can check this again...but i don't make a breaking version just to rename it again now. Hope you understand...if you prefer an other naming you easily can write your own wrappers like we did for the old names (translate, I18n)

[Dremora]

The component doesn't consume namespaces from the context but rather translation data. TranslationConsumer seems like a more meaningful name. withNamespaces could also be called withTranslations.

[jamuhl]

@Dremora Do you have multiple namespaces - or only one?

[jamuhl]

But at least i start to agree (still open to learn 😄)...namespaces seems to make no sense to new users not familiar with the term used in i18next

[Dremora]

We have multiple namespaces that we pass as a prop to NamespacesConsumer. But the fact that it accesses strings from multiple namespaces doesn't mean that it needs to have Namespaces as part of the name. The main thing that it makes available to children is the translate function. If there was only one namespace (or no notion of namespaces altogether) the idea would stay the same.

[jamuhl]

Hm...again - the main thing it does is asserts the availability of those namespaces...passing down t is the simple part of it.

withI18n passes down t even the provider passes down t - all the things pass down t

just the withNamespaces, NamespacesConsumer assert those translations get loaded and are loaded (if set ready true) and as a bonus pass down a t function fixed to the first namespace given.

But if everyone agrees withTranslations and TranslationConsumer is a better naming we can add that...might be easier to understand for users...so why not?

[Tobbe]

I agree that withTranslations and TranslationConsumer are better names

[jamuhl]

Will land with the new hook based version:

useT for hook

withT for hoc

https://github.com/i18next/react-i18next/issues/590

[jamuhl]

https://github.com/i18next/react-i18next/issues/591

won't land - there won't be another major version after v9 so there will be no time to deprecate the namings -> v8, v9 will die with the current namings

we might keep the legacy names in v9 translate, I18n?!? (without warning about using the other new names)

[jamuhl]

closing this for now...plan is to keep old and new namings in v9 - while having improvement in v10 based on hooks