Allow usage of markup in addition to rich values in defaultTranslationValues

[neverether]

Is your feature request related to a problem? Please describe.

In my app I'm using both t.rich and t.markup relatively often, and the majority of the tags in use are common ones like: strong, br, i, etc. For rich translations, I'm utilizing defaultTranslationValues in my provider but I'd also like to specify the appropriate strings for the same tags except for markup support.

Describe the solution you'd like

Potentially extending the config of defaultTranslationValues?

Describe alternatives you've considered

Haven't come up with an idea yet.

[amannn]

Hmm, I see. Therefore the default values you provide for t.rich can't be used for t.markup since in one case they should return React elements and in the other plain strings, right?

There's currently a discussion around whether defaultTranslationValues should be deprecated in #611, as it has a few issues:

1. We can't add strict TypeScript validation for args passed to t if there are potential global values.
2. The default values can't be serialized across the Server Components boundary to be made automatically available in Client Components.
3. Your issue described here (new)

There hasn't been a decision around this yet, but your issue seems to add one more bullet to this list. For the time being, I'd suggest looking into the alternatives mentioned in #611 and use one of those patterns.

Hope this helps!

[neverether]

Hmm, I see. Therefore the default values you provide for t.rich can't be used for t.markup since in one case they should return React elements and in the other plain strings, right?

That's exactly right.

Apologies, I didn't find that topic when searching earlier. For what it's worth, when going through the documentation for the first time (I just migrated my entire app from next-i18next), I thought the global defaultTranslationValues was potentially a double-edge sword as it also obfuscates the full set of values to a newly onboarded team member for instance.

I personally wouldn't mind doing something like: {t.rich("foo."), { ...defaultRichValues, foo: (...)}) in any case. It's a little verbose but more explicit.

However I also would definitely not like to see this move into a direction like the common <Trans> components in some other libraries, I find this api much easier to work with, passing chunks in. Just my 2 cents.

[amannn]

I thought the global defaultTranslationValues was potentially a double-edge sword as it also obfuscates the full set of values to a newly onboarded team member for instance

Yep, I agree. The alternatives are more verbose, but I think overall the gain in explicitness and more compatibility / less surprises should be worth it.

not like to see this move into a direction like the common <Trans> components in some other libraries

Yep, also agree here. We're not going there 🙂

Thanks a lot for sharing your perspective!

I'll close this issue for the time being in favor of #611, your point is noted there now.