j-schumann

+1

+1 on this one, it is ok (for us) to return "ns:key" if the key doesn't exist in the locale file, but not if I explicitely defined the translation to...

Hello @aralroca, do you think it would be sufficient to simply change the current behavior (meaning: interpret it as a bug that can be fixed without a new major version)?...

Hello @aralroca, I would like to bring this up again: While the suggested approach works for many/simple cases it is not convenient for multiple reasons: a) I would like to...

Hello @aralroca, I have a rudimentary implementation here: https://github.com/j-schumann/next-translate/commit/31bc4e0f28f8a670f429059989cb006bd572efd4 The main part that is missing is supplying the current locale to the user's formatter function. How can we get the...

Do you have any suggestions on how to get the locale into the formatter function? WIthout this the feature is probably not very useful. Maybe wrap the user-supplied function in...

Hello @aralroca, what is the status of this? > In these releases we are focused on bugfixes so for the moment we don't want to introduce new features, but for...

@aralroca Seems to work, tested with some formatters. Thanks, now I can finally drop my custom patched 1.0.7

@aralroca Ok, not quite: `t("common:default.date", { value: project.createdAt })` causes: ``` Type 'string | Date' is not assignable to type 'string | number'. Type 'Date' is not assignable to type...

I was missing this feature too. Maybe this custom loader can be used in development while for the build process the plugin triggers this loader and stores the result (`{...