i18n.t and t not working the same?

[abjorck]

I was expecting them to, but maybe that is wrong of me.

Anyway, the issue I have is that when using sprintf.overloadTranslationOptionHandler (from https://github.com/i18next/i18next-sprintf-postProcessor), the t() does not work as expected.
(I'm using the translate() HOC)

It seems to be that t() uses getFixedT and somewhere in there the arguments are mangled, while i18n.t() works as expected.
I also found this issue which may be related, i18next/i18next#565

So maybe the question is, can I get t() to act the same as i18n.t()?

TLDR;
(with key schedule.week being something like "Week %d")
{ i18n.t("schedule.week", moment().week() ) } works
{ t("schedule.week", moment().week() ) } does not "resolve"

also, for added info, the long form works:
{ t('schedule.week', { postProcess: 'sprintf', sprintf: [moment(startDate).week()] }) }
but that doesnt look very nice.

[jamuhl]

yes you found the right location for the problem - using getFixedT which takes a somehow naiv approach only supporting the defaultValue handler.

https://github.com/i18next/i18next/blob/master/src/i18next.js#L231

if we replace that with the same functionality used in translator:

https://github.com/i18next/i18next/blob/master/src/Translator.js#L45

that should work for every handler...if you like you could provide a PR or i will look into this asap.

[jamuhl]

should work in [email protected]

[abjorck]

It does, nice! Thanks for the quick work

[jamuhl]

awesome...thanks for confirmation.